Prevent Editing Previously Submitted Repeats

[ZachBodenner]

Hello,

I have a three surveys built on the same feature service. In Survey B, the repeat section is exposed while in Survey A it is not.  The goal is to have a members of the public submit Survey A then receive a link that allows them to go back and edit information they added via Survey B, including adding repeats (in this case representing comments). Members of my organization should also be able to add repeats via Survey C (build on the same service, but with ONLY the repeat section exposed). I've tested all of the surveys and they would just fine in terms of data submission, but one important aspect is that neither the public nor org. staff should be able to edit a previously submitted repeat.

I've looked around and came across this pretty straightforward solution of adding allowUpdates=false allowAdds=true to the bind::esri::parameters column of the repeat. I tried it out and previously submitted repeats are still editable. Have I missed something, or are there any other solutions or workaround that  might help achieve my goal?

[SMH-Rio]

In this case, my first option would be to create different forms, pointing to different view layers (which would have different filters too). I don't know if it makes sense in your case.

[ZachBodenner]

I actually had already kind of done that for testing purposes, and this solution actually works really well. I'm going to mark it as a solution, though I'm still interested in chasing down the calculation route just for learning's sake.

[abureaux]

Have you tried using "date" yet?

Add a dateTime field in the main survey body. Make bind::esri:fieldType = null, bind::esri:parameters = calculationMode=always, and appearance = hidden

Then add a dateTime question to the repeat. Make appearance = hidden and default = now()

Then you can use an IF() statement in the readonly parameter for the individual fields within the repeat. If the dateTime outside the repeat is greater than the repeat dateTime (maybe by 5-10 minutes?), readonly = yes.

EDIT: Or, similar approach. If you could feed a uuid into the survey, just make a new uuid every time the link is pressed, and the repeat is only editable when the uuid within the repeat matches the one outside.

[ZachBodenner]

Fortunately I already had some date fields available to work with! So there's the DateCreated, which is automatically filled out with the current date when the initial request (SurveyA in my initial post) is made. Similar with the CommentDate, which is set to Now() when a new comment repeat is added. 

Now I don't know if it's just my syntax, but I can't advance past the Survey123 Connect error I get when I try to save and update the form with that read-only parameter entry. Am I missing something with the setup you suggested? Bad IF statement writing?

[abureaux]

Likely just a syntax issue. I see two off-hand:

1. Contrary to how I always tend to reference them in text, IF() statements in S123 really don't like being capitalized. Change your "IF" to "if".
2. Your "yes" and "no" should be in quotes.

[ZachBodenner]

Aha yes, well that got past the error, but unfortunately it did result in a change in the form behavior. I also tested out stripping the repeat date out and just replacing it with now:

if(${DateCreated}>(now() + 0.0104166675),'yes','no')

but that didn't make a difference either. I was following Ismael's blog about using dateTime comparison/calculation which is how I arrived at the + 0.0104 etc number as a test. So I figured I'd also get rid of that time add and just try it against now(). So here's my test form with three different readonly contingencies:

And all of those fields remain editable

[TrafficOpsGIS]

Had similar issue with repeat editing. Embed the Survey into Dashboard as embedded content(Web Form). Oddly I pointed the layer at the view of my survey hosted feature. Even when I made the form window view only and pointed at the view layers. Because I had allowAdds=true allowUpdates=true query parameters. It still creates additional or deletes repeat record(responses). Look into using the query functionality. Or what I did. Create a separate form windows. The first is mode=copy. The second mode= edit. Removed the field being edited from first window and only show it on the second. Here is the syntax to the first - ?mode=copy&globalId={field/globalid}&hide=field:date_historic,....leaveDialog&version=latest

To the second - ?mode=edit&globalId={field/globalid}&hide=field:communication,................,leaveDialog&version=latest.

Hope this helps.