nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

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?

Vind meer berichten getagd met

Accepted answers

SMH-Rio

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.

All comments

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

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)

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:

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".
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

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.

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.

View_UpdatedDelete_Example.PNG

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.