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?

[abureaux]

Did you add "query"? query allowUpdates=false

However, note that the default behaviour is allowUpdates=false, so I don't think there is value in specifically specifying it. Same deal with allowAdds, which defaults to true.

[ZachBodenner]

I did try that as well, yeah, though I suspect since there was no change that it's just that the bind::esri::parameter isn't honoring that syntax in the web form (which seems like based on RobertAnderson's idea) Hopefully that gets fixed.

[abureaux]

Thanks for linking that idea! Voted.

[SMH-Rio · Accepted solution]

Is it important to view previous repetitions within the editing form? If not, you could filter the comments/repetitions table with a condition that will never be met (e.g.: globalid='test'). This way, the layer will never return previously submitted records, but will allow new ones to be submitted. This way, your data is preserved and new entries can be added:

I usually use this trick when I don't want my users to be able to view and edit records in the Web App.

[ZachBodenner]

I like the thought, but how do you do this publishing from Survey123 Connect? Usually you can't publish with the GlobalID entered as a question line, correct?

[abureaux]

Try this approach: Pull the ObjectID of existing features into a Survey123 form

[ZachBodenner]

Okay, so closer (thanks @abureaux !), but @SMH-Rio  where do you do the actual filtering? My first thought was the relevant column:

...but that just disappears the entire repeat section (good for not editing previous entries, bad for adding new ones)

[SMH-Rio]

In my workflows, I only need users to not edit already submitted repetitions when they open the record in the Web App (there is no other relationship with form fields - I just need to simulate the 'allowUpdates=false' from the Field App).

In this case, I do the filter directly in the layer that receives the responses from Survey123 (I don't do anything in xlsxform). I used the globalId as an example (because I can publish surveys with the global and parent), but in reality, it could be any other column in the database: the condition just needs to never be met. In other cases, I've done 'objectid = 589237598723598327', for example. The trick is that the condition is not met, regardless of the column used in the filter.

I hope this helps you.

[ZachBodenner]

Ah yes okay that does make sense. As it stands now I need the records to be visible to internal staff, just not editable by anyone who accesses the web form, though I can think of some ways to work around that.