topic Re: Calculate field not working properly after saving a draft in ArcGIS Survey123 Questions

Calculate field not working properly after saving a draft

RSchaffner — Fri, 13 Jul 2018 15:55:17 GMT

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.

Re: Calculate field not working properly after saving a draft

JohnathanHasthorpe — Wed, 18 Jul 2018 00:53:49 GMT

We have made a change to the way that the inbox and drafts do calculations, as a result of user feedback and bugs raised. Essentially, users were unhappy about the fact that when a survey was loaded/opened, calculations would fire and values would be overridden - even if the user had manually typed something in. To make the behavior more predictable, on load from the Inbox or Drafts, the survey values will match whatever was entered in the form when it was submitted/saved - i.e. no calculations will run.

However, when you update the values in the form - calculations should be triggered if they reference another question that has changed. This looks to be a bug and we will get this looked at. For the time being, the user will need to manually recalculate if working from drafts/the inbox.

Thanks

John

Re: Calculate field not working properly after saving a draft

OlivierDemars1 — Thu, 19 Jul 2018 18:36:27 GMT

Hi,

I noticed a similar issues and, after doing some testing, I found out that the behavior is different for a text field and for integer, decimal and date fields.

Using the attached Survey123, I open it and save it directly as draft without entering any data.

After opening the data and entering information in the 4 fields (text, integer, decimal and date), only the read only text field is updated. The read only integer, decimal and date fields are not updated.

Best,

Olivier

Re: Calculate field not working properly after saving a draft

JohnathanHasthorpe — Mon, 23 Jul 2018 01:54:59 GMT

Thanks for the feedback - we will look at this when we fix this

Re: Calculate field not working properly after saving a draft

RSchaffner — Mon, 23 Jul 2018 13:31:57 GMT

I just found out from people using a different survey that Calculate is also not working on both a select_one and a text field within a repeat group after saving a draft. Data was saved for other text and select_one fields within the repeated group, and the only difference is that the questions that failed to save are "relevant" based on another field. This is a big problem, as people in the field lost data this weekend. How long before this is fixed, or is there a way to revert to the earlier Survey123 version on mobile devices?

Re: Calculate field not working properly after saving a draft

JohnathanHasthorpe — Tue, 24 Jul 2018 12:00:55 GMT

Hi - What platform are you using for the field devices?

Re: Calculate field not working properly after saving a draft

OlivierDemars1 — Tue, 24 Jul 2018 14:14:05 GMT

Hi, we had to stop all our Inbox based form activities due to the issues on calculate. Our users are all on Android.

Re: Calculate field not working properly after saving a draft

RSchaffner — Tue, 24 Jul 2018 15:16:16 GMT

Both MacOS and Android, most people seem to have the latest versions.

Re: Calculate field not working properly after saving a draft

JohnathanHasthorpe — Tue, 24 Jul 2018 23:00:11 GMT

You can get your users to download version 2.9 of the app from here: Survey123 for ArcGIS | ArcGIS

This will have the same functionality as 2.8 so you can continue using this while we fix this in 3.0.

Please let me know if you need any assistance.

Thanks

John

Re: Calculate field not working properly after saving a draft

RSchaffner — Wed, 25 Jul 2018 15:55:23 GMT

But those downloads of 2.9 are not available for iOS, correct?

Re: Calculate field not working properly after saving a draft

JohnathanHasthorpe — Thu, 26 Jul 2018 02:34:36 GMT

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

Thanks

John

Re: Calculate field not working properly after saving a draft

JohnathanHasthorpe — Thu, 02 Aug 2018 06:48:05 GMT

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

Re: Calculate field not working properly after saving a draft

ChrisCzerwinski — Thu, 24 Oct 2019 18:50:12 GMT

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

Re: Calculate field not working properly after saving a draft

JamesTedrick — Fri, 25 Oct 2019 21:08:39 GMT

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.

Re: Calculate field not working properly after saving a draft

ChrisCzerwinski — Mon, 28 Oct 2019 13:26:33 GMT

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

Re: Calculate field not working properly after saving a draft

JamesTedrick — Mon, 28 Oct 2019 22:08:54 GMT

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

Re: Calculate field not working properly after saving a draft

Mondi_GIS — Wed, 30 Oct 2019 10:46:57 GMT

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.

Re: Calculate field not working properly after saving a draft

ChrisCzerwinski — Wed, 30 Oct 2019 13:29:36 GMT

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

Re: Calculate field not working properly after saving a draft

DougBrowning — Wed, 30 Oct 2019 15:49:51 GMT

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

Re: Calculate field not working properly after saving a draft

ChrisCzerwinski — Thu, 31 Oct 2019 11:25:37 GMT

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?