Issue with Draft, Required Field, Repeat, and Repeat_Count

[ErikHerbergMETC]

I'm having issues with repeats when a form is resumed from Drafts. I've seen several posts about issues with Drafts and/or repeats, but didn't see a post with this specific example.

I've created a simple form that has one repeat, the repeat_count is set to 3, and the repeat has one required question. The form works fine when filling in a new form from Collect. However, the issue occurs when the form is saved as a Draft while still on the first repeat, and then resuming later. On resuming, the form will get stuck on the second repeat. Even though I click an answer for the select_one on the second repeat, Survey123 still gives me the Required message warning and I can't progress back to the first repeat or on to the third repeat. 

My steps to trigger this: Start a new form from Collect, immediately save as Draft, open it from Draft, try to answer the question and advance to the next repeat. It works fine of the first repeat, but gets stuck for me on the second repeat. 

Do I have something wrong? Is this a bug? Is there a workaround? 

Thanks for any help! XLSForm is attached. I'm using Windows - Connect version 3.12.230 and Field App version 3.12.277. 

[DougBrowning]

Funny I just posted about this again today here

https://community.esri.com/t5/arcgis-survey123-blog/what-s-coming-in-arcgis-survey123-september-2021...

and here

https://community.esri.com/t5/arcgis-survey123-questions/calculate-field-not-working-properly-after-...

A bunch of calcs will not fire from drafts.  It has been a major issue for us.  

As you can see the posts go back 3 years with many more in the last year.  I have not seen it on the radar and have not get a response.  

Hopefully more can add to this post that it is an issue.  Thanks!

[Anonymous User]

Hi @ErikHerbergMETC ,

I replied in your other post also, the issue you are encountering is with repeat_count and saving to Drafts, which is a known issue and is logged as BUG-000127011. Unfortunately the underlying problem has yet to be resolved and won't be fixed in upcoming release (3.13), but something we are working on and will hopefully be addressed along with some other repeat and nested repeat issues.

The only workaround in the meantime is not to use repeat_count if you need to save to Drafts, otherwise values in the repeats can not be edited or added once you open the survey from Drafts again.

Regards,

Phil.

[DougBrowning]

Is that bug # correct?  

BUG-000127011 is When using the Survey123 for ArcGIS field app, an image attachment disappears when the survey is edited from Outbox having a 'repeat' set with image question.

That is not it I think.  Thanks

Also I am not using repeat count anymore but my calculations still break when going to draft.

[Anonymous User]

Hi @DougBrowning,

Yes that bug # is the same issue, while the description is very specific to image attachments and Outbox, the problem is the same. When you save to Drafts and re-open, or try to open the survey to edit from any other folder such as Sent or Outbox, if using repeat_count the values entered into a new repeat records that previously had no values will not be saved. Removing repeat_count resolves this issue.

The problem you are seeing without repeat_count would be different, likely cuased by nested repeats I assume?

Regards,

Phil.

[DougBrowning]

Yep the nested repeats.  You have my list of the bugs for this already.  Thanks!

[DougBrowning]

@ErikHerbergMETC  what I ended up doing to get around this is use a constraint on a counter instead.  I used to use once(count()) but now you can use position({repeatname}).  You can set a constraint on that count and it will work mostly the same.  Further I added a warning to the user.  

My example has 32 repeats.  It uses pulldata to get 1=A, 2=B, etc.  At repeat 32 I have it pulldata a message saying Opps went to far delete this repeat.  (In another form I have a relevant message that pops up at > 33.)  Then I have a constraint on a field with a calc of position({repeatname}) - it is just . = 32.  So I give them a warning and I stop them from being able to submit.

In the end it works much better than repeat count.  Repeat count causes all kinds of calculation issues for me since it preloads all the records.  Used to cause memory issues also.

I hope that makes sense it is early.  It is a solid workaround for now.

[Antonio_MarcosPires_Martins]

Hey Doug, how are you? I would like to understand in more detail about this workaround that you posted. Could you please give an example of how I define this on my form? I appreciate the attention.

Antonio

[DougBrowning]

Depends where you want it but for me we have a summary page of info. 

One of these is Points Competed.  I have this field with a calc of count(${PointNbr}) - PointNbr is just a field in the repeat that is always there.  Does not really matter what it is since you are just counting them up.

Then I put a constraint on this field like . = 50.  That way there must be 50 repeats.

In the end you are just counting how many repeats there are by counting a field inside the repeat.  Then you are checking to see if the number of repeats is what you want.

Does that make more sense?

[ErikHerbergMETC]

Thanks! I will keep my fingers crossed for a fix for that bug in a future release. 

For anyone else who might stumble on this, here is the where I made the other related post Phil mentioned.