Calculate field not working properly after saving a draft

[RSchaffner]

This may be a new issue in the latest version of Survey123 (3.0.132) because I didn't notice it prior to the week of July 1. I have 4 groups of select_one questions that culminate in a calculated field (sum of the integers from the select_one answers) that is also set to read only. If the survey is started and completed in one attempt, everything works fine. However, it's a long survey, so inspectors often need to save drafts and return later. After reopening the survey, they find one of two things: 1) The select_one answers in each section no longer appear filled in, although the summed field still displays the correct number. 2) Upon starting a new section of select_one questions, the calculate field for that section does not update properly. 

I can remove the read-only option from the calculated fields, but the user is then required to press the refresh icon next to the calculated fields to make them update, and I worry that they will forget to do this, resulting in numerous errors in the data. 

Is there a setting I can adjust to make these fields autocalculate in all situations? I am attaching a truncated version of the survey .xls. The calculated fields are highlighted in yellow. 

[DougBrowning]

Probably.  I have had weird repeat behavior whenever there is an if.  It tends to kick off the calcs again as James was saying.

Just put in a 3 and see if that fixes it.

[ChrisCzerwinski]

Thanks Doug Browning‌ for the tip, I will report the result back here asap.
Cheers, 

Chris

[ChrisCzerwinski]

Hi Doug Browning‌ and James Tedrick‌, I took the advice to switch up the syntax for the repeat count to "3".  That didn't seem to solve the problem.  Just to test, I then changed the data type for ${sample_num} from integer to text  (legacy fixes for this bug seemed to be addressed for text fields first).  Changing the data type also didn't solve the problem. 

After all this, I turned off "read only" for the calculated fields involved in the bug.  I wanted to see if I could manually refresh them when reopening a survey from Drafts.  With these settings, after opening from Drafts I can obviously manually edit the fields (not ideal) and refreshing seems to work, but then when I move to the next record in the repeat, Survey123 gets stuck on ${sample_num} and displays "required !" regardless of it visually appearing to have a data value... and then I can't move forward to the next related record even though all required fields are seemingly populated and valid (visually).

[JamesTedrick]

Hi Chris,

I can see the behavior you are describing with the Sample Number.  Given that it is read only, could you remove the required property from the Sample Number?

[ChrisCzerwinski]

Thanks James, 

It's not ideal, but to test, I tried removing the required property from ${sample_num}.  The same behavior moves to the field called ${collection_area_ID} when opening a survey from Drafts.

In theory I could remove all the fields in the "Sample Info" group, except for Sample Number.  That's what makes the related record unique under the protocol the data is being collected. Using AGOL's global_Ids,  collection_area_id could be calculated when downloading to a local geodatabase.  However, I am taking advantage of a watermark that pastes collection_area_id on a required field photo, so there are other reasons to calculate these fields.

Multiple partners will be using this app, and contributing their data to a centralized database for further QA/QC procedures.  The calculated fields, and subsequent watermarks were intended for the data's end-use.

Given that this issue will most likely come up for other users, I'll need to find a work-around. 

Any suggestions are appreciated, thanks,
Chris

[ChrisCzerwinski]

To add to my test, I turned off the required and read only properties for all fields in the "Sample Info" group.  When pulling up an incomplete survey from drafts, the same behaviour happens with the next required field on the page.  ${sample_num} refreshes off the repeat count as expected, but a refresh for ${collection_area_id} is missing the concatenated ${sample_num} component.  Any fields with relevant dependencies also seem to be thrown off.

 

 

[PatrickCrushell]

Can anyone confirm whether this has been fixed...? I am finding thread hard to follow.

When I save a form to drafts where no select multiples have not been selected and then open from drafts and select multiple choices a read-only calculation field based on the multiple choices (count-selected) does not update (note type)...

Similar issue arises in a text field where calculation is property('username') where a form has been saved to draft by user who is not signed in. When they open the saved form (while signed in) the required read only field does not populate and therefore form cant be submitted....

Any advice?. I do not want to turn off read only due to potential user error.

[DougBrowning]

I have run into this issue again today in 3.11.  Seemingly random calculations and relevant statements are getting stuck when opening from drafts.  May be connected to items in a nested repeat but not always.

We need to change between some forms while in the field.  Logically I would think opening from Drafts it is still a "new" form and all calcs and relevant should work just like it was new.

Since you cannot have more than one form open at a time (but this would be so sweet!).  How are we to accomplish flipping around?  Or is this actually a bug?  Sounds like based on this post it is a bug.  I can send samples if you like.

Thanks

[Anonymous User]

Hi Doug,

Do you see the same in issue in 3.10, or just 3.11 beta with loading from drafts?

You are correct, all values, calculations and relevants should be loaded when opening from drafts, in the same state as when the form was saved. It sounds like the issue you are seeing is with the nested repeat questions only, and not the parent repeat or parent layer.

I have sent you an email, will take a look into this issue, and if you can also raise a bug with Esri Support that would be great.

Thanks,

Phil.

[DougBrowning]

Seeing it in both 3.10 and 3.11.

So far I can only say I am seeing it for sure on the second repeat of a nested repeat.  So open a form with a nested repeat.  Both the top level and the nested have a repeat count.  Scroll though the top level a few times (go to 5 of 20 or something).   Save as draft.   Open back up.  Go to any top level repeat.  Go into the nested repeat and scroll to the second repeat and no calcs work on that second repeat.  1st repeat seems to work just not number 2.

It is happening on all my forms.  Taking out repeat count seems to do it and I have now had to remove them from all of my forms.  I am not referencing anything in the parent in at least one of them but it still does it.  I will send a sample form.

I hope that makes sense.