Calculate field not working properly after saving a draft

7619
36
07-13-2018 08:55 AM
RSchaffner
New Contributor III

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. 

0 Kudos
36 Replies
JohnathanHasthorpe
Esri Regular Contributor

Hi - Yes, that is correct. If you need iOS please email me on jhasthorpe@esri.com.

Thanks

John

0 Kudos
JohnathanHasthorpe
Esri Regular Contributor

HI All,

We are working on a fix for this issue (calculations not firing in drafts and inbox) and have released new builds to the EAC: Welcome to our Feedback Community. We will also be making iOS builds available through Test flight.

Builds are 3.1.7 field app and 3.1.6 Connect.

The fix has been implemented for text and numerical questions only (not dates or select_one/select multiple questions). Please test the builds on your surveys and confirm that they are now working as you expect.

Once confirmed, we will apply the fix to all question types and get this releases as a hotfix.

Thanks

John

0 Kudos
ChrisCzerwinski
New Contributor III

Is this still an issue?  Or are there any known workarounds?  I have a couple read-only calculated fields in a repeat that are causing this very issue.  It's only an issue if an incomplete record is saved to drafts (to be edited later), and all calculations haven't been triggered.  

Thanks, 

Chris

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Chris,

As Johnathan indicated above, this was resolved in the 3.1 timeframe (last fall).  

Can you provide more details on the problem you are seeing?  One thing to note is that if the value in a question differs from the value of the calculation upon opening from drafts, Survey123 will assume that the difference is intentional and not fire calculations to preserve the already-entered value.  This can cause a similar-looking effect to what was described in this post.

0 Kudos
ChrisCzerwinski
New Contributor III

Yeah I thought it wouldn't have been an issue based on the 3.1 fix for text and integers as well.  My problem appears to be on a read only required calculated field (integer), which is based on the repeat count ('1 of 3', '2 of 3', etc.).  I'm using the syntax "once(count(${site_visit_rel}))+1" to calculate for this read only field (${sample_num}). 

So, ${sample_num} = 2 for the second related record in the repeat, which is used to build a unique id for that related record (${collection_area} =${site_visit_id}+"-"+${sample_num}).  I have the survey set to require 3 related records in this repeat.  Everything works fine if a survey is submitted offline in the field (all required fields are honoured/submission accepted).  But, if all three related records are not initiated before the survey is saved to Drafts, it will not fire these calculated fields when opened for editing at a later time.  This isn't an issue from the inbox, since the data validations prevent an incomplete survey from being submitted. 

An easy fix would to enable editing on ${sample_num}, but then I'm opening up the opportunity for human error...

Thanks for your time,

Chris

0 Kudos
JamesTedrick
Esri Esteemed Contributor

Hi Chris,

Given your description, it sounds like the calculation is being affected by the calculation difference check that I mentioned.  One workaround would be to have the repeat number populate a read-only text field; if you are also using repeat count to create the repeats, that would provide 3 valid repeats from the start (a repeat is not valid if only hidden/calculate questions are populated).

0 Kudos
Mondi_GIS
Occasional Contributor

James Tedrick‌, We are experiencing a similar issue on Android and Windows devices. 

We have a form which has nested repeats  which auto-increment up to a specified/calculated number of repeats based on earlier field (area in ha). This form works well when using it normally, but we have picked up that when you save it as a draft or close Survey123 and recover the incomplete survey the unpopulated repeats lose their calculations and validation, and you can’t scroll to the rest of the incomplete repeats.

 

So, for example, I am completing a survey which has auto-incremented up to 5 repeats.

I complete repeat 1 & 2, and accidentally close my app.

When I reopen the app, I can scroll to repeat 3, but the calculations and field validation is missing.

I cannot proceed beyond repeat 3 to repeats 4 & 5.

0 Kudos
ChrisCzerwinski
New Contributor III

Just to share out my XLSform on this issue.  Similar XLSform structure to Admin Admin

0 Kudos
DougBrowning
MVP Esteemed Contributor

Why do you have an If statement if the answer is always 3?

0 Kudos
ChrisCzerwinski
New Contributor III

Good point Doug Browning‌.  The survey was originally developed so that if "no" was selected, there would be no repeat available... it was requested later to instead thin out the data collected within the repeat if "no" was selected.  An oversight on my end I guess.  Do you think this line has something to do with my issue?  

0 Kudos