Select to view content in your preferred language

Prevent Editing Previously Submitted Repeats

590
16
Jump to solution
08-08-2024 05:48 AM
ZachBodenner
MVP Regular Contributor

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?

Tags (2)
0 Kudos
1 Solution

Accepted Solutions
SMH-Rio
Frequent Contributor

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:

SMHRio_0-1723135034058.png

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

View solution in original post

0 Kudos
16 Replies
abureaux
MVP Frequent Contributor

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.

0 Kudos
ZachBodenner
MVP Regular Contributor

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.

0 Kudos
abureaux
MVP Frequent Contributor

Thanks for linking that idea! Voted.

0 Kudos
SMH-Rio
Frequent Contributor

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:

SMHRio_0-1723135034058.png

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

0 Kudos
ZachBodenner
MVP Regular Contributor

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?

0 Kudos
abureaux
MVP Frequent Contributor
0 Kudos
ZachBodenner
MVP Regular Contributor

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

ZachBodenner_0-1723472967758.png

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

 

0 Kudos
SMH-Rio
Frequent Contributor

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.

0 Kudos
ZachBodenner
MVP Regular Contributor

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.

 

0 Kudos