Select to view content in your preferred language

Saved draft when re opened does not include all data in version 3.14.237

1060
4
Jump to solution
03-09-2022 02:48 PM
JaneRobbins
Emerging Contributor

I have a  survey in which fields and groups are displayed dependent on the answers to previous questions - using the relevant column. The survey all used to work ok. But since the app has updated to 3.14.237 we have the following problem: If the user completes the survey in one go and uploads then it all works ok. But, if the user saves the survey response to draft and then re opens the draft values for many of the fields are lost. I.e. those fields and groups that were relevant only if the first question had a specific value.

On my desktop I filled in the form, saved draft and looked in the sqlite DB - all the fields were saved ok.

I opened the draft - fields were not shown. I immediately saved that to draft again and looked again at the sqlite database. The fields were all missing. 

Survey excel file (see row 105) and the 2 draft results attached (1 is the first draft and 2 is the reopened and resaved draft).

0 Kudos
1 Solution

Accepted Solutions
ZacharySutherby
Esri Regular Contributor

Hello @JaneRobbins

The source for the issue is the expression set in the required column for the insitu_visual_assessment question. Any question that has a relevant expression subsequent to the insitu_visual_assessment question will experience the behavior. The reason this started with 3.14 is we made a significant overhaul of our expression pipeline to resolve a number of crashes that were observed in previous versions. 

We've created an internal issue for this behavior, please feel free to reach out to Esri Technical Support and they will be able to assist with getting you attached to an official BUG. 

As a workaround in the meantime if you move your expressions from the required column to the body::esri:visible column that will resolve the behavior. 

Thank you,
Zach

View solution in original post

0 Kudos
4 Replies
ZacharySutherby
Esri Regular Contributor

Hello @JaneRobbins

The source for the issue is the expression set in the required column for the insitu_visual_assessment question. Any question that has a relevant expression subsequent to the insitu_visual_assessment question will experience the behavior. The reason this started with 3.14 is we made a significant overhaul of our expression pipeline to resolve a number of crashes that were observed in previous versions. 

We've created an internal issue for this behavior, please feel free to reach out to Esri Technical Support and they will be able to assist with getting you attached to an official BUG. 

As a workaround in the meantime if you move your expressions from the required column to the body::esri:visible column that will resolve the behavior. 

Thank you,
Zach
0 Kudos
AdriannaBarton
Occasional Contributor

Hi Zach, I am having a slightly similar issue, but with relevancies based on other fields. Everything functions perfectly in a collect form, but when it is inboxed these fields are showing up blank/clearing out. The relevancies are calculated within the form, and these calculate fine in the inbox ( I have verified using note fields). I just tried to see if maybe removing the relevancies and putting them in the visible field would work but it did not. Any suggestions for this?

0 Kudos
EvanR
by
Occasional Contributor

Hello @ZacharySutherby,

I am having a similar issue. I have a survey with 50+ questions, of which 3 do not store selections when I save to draft. Many fields have expressions in the Relevant column and/or Required column. The workaround described is not an option for me because I need fields to be visible even when their conditional Required expressions evaluate to false. Any suggestions? I cannot share the XLSForm publicly but can send it to you directly if needed. All affected questions are outside of repeats; one is a text question and two are select_one questions.

Thanks,

Evan

0 Kudos
JaneRobbins
Emerging Contributor

Thanks @ZacharySutherby 

That workaround appears to have worked successfully. Just took a while to do and test though.

0 Kudos