Select to view content in your preferred language

Survey123 3.6.155 not auto-calculating inside relevant group

1545
4
10-10-2019 04:30 PM
JakeJacobs
Frequent Contributor

I have a survey that works as expected in the earlier version of Survey123 but in 3.6.155 (iOS) I get unexpected behavior.

I have a group which has relevancy set.  Even when the group is relevant within the form, some of the autocalculations are not occurring. If I move them outside the group, they perform as expected.

The reason I have the entire group of questions wrappered in a relevant group is so that the form cannot be opened directly from Survey123.  The questions in the form only become relevant when the form is being opened from a custom url passed from Collector which passes a feature GUID.

I'm particularly surprised that the row of type username  doesn't calculate.  It's not dependent on anything being passed into the form from the URL.

I've attached the version of the form that fails in the new version of S123 but worked as intended in the old version and then a version of the form which works in the new version. 

I'm lucky in this case that the calculations are ones that are hidden from the user so I don't mind where they are located in the form, but I have other more complex forms that are not that way. 

I saw this discussion about calculations within non-relevant groups but I'm not sure if the behavior I'm experiencing is related or not, since my group is relevant.

https://community.esri.com/thread/241140-calculation-question 

Philip Wilson

0 Kudos
4 Replies
by Anonymous User
Not applicable

Hi Erika,

I had a look at your survey xlsx and can see what is happening and why it no longer works in 3.6, even though it previously did in 3.5 or earlier. It is not related to the default values and non-relevant questions bug being fixed, but is related to another bug we fixed in 3.6 related to using relevant expression on groups.

When a relevant expression is applied to a group (begin group) all questions inside that group should inherit the same relevant expression. In 3.5 and earlier, this was not working correctly, and whilst the group was hidden from the form, the actual questions we still relevant and could accept values, even if not displayed. The correct behaviour is that if a group is not relevant, so are all the questions inside it, and therefore those questions can not have values.

In your case, the relevant expression on the begin group ${COLLECTOR_GLOBALID}!=(0) is using a value from a question that is inside the group, which is a hidden question ${COLLECTOR_GLOBALID}. In this case it will not have a value on load, nor never get one, as it is not relevant until the group becomes relevant. The way the form loads and runs all expressions and calculations in order down the form would mean it never gets a value in this case.

The correct way to set up this form would be to move the ${COLLECTOR_GLOBALID} hidden question to the start of the form, outside of the group and before the note and begin group question. That way it will get a value, and the following questions can be evaluated and the expressions executed based on the value in that first hidden question. You may also want to move the other hidden questions outside the group also that are getting their values from the URL scheme passed from Collector, otherwise all of these values are going to be null on initial load when the group is not relevant and then when the group becomes relevant the values will not be there.

Hope this helps.

Regards,

Phil.

JakeJacobs
Frequent Contributor

Thanks Phil, this is helpful.  Now I see why the behavior of the things related to the COLLECTOR_GLOBALID weren't working in 3.6.


Can you explain why the row of type username doesn't populate if it's inside my relevant group vs being outside of it? 

This one is still a puzzle.

0 Kudos
JakeJacobs
Frequent Contributor

One more question about this.  As I'm testing, if I have a non-hidden question inside a relevant group, and I'm passing that information in from Collector in the custom url scheme, it appears to still populate.  Based on your above description I expected that it would be empty, which worried me because then I'd have to temporarily store everything I passed from Collector in a field outside the relevant group and then fetch it in from the form itself.  But in my test, I was able to pass a value from Collector into a field inside a relevant group.  Do hidden vs visible questions act differently?

0 Kudos
by Anonymous User
Not applicable

Hi Erika,

As for why you are seeing some questions populate and others not, it all depends on the order that the questions and expressions and evaluated and executed when the form first loads. The order of operation is not sequential and is not the same as the question order. It is based on question order as well as the relationship to other questions based on expressions (relevant, calculations, read only, required etc). If a question has an expression that requires the input from another question then that question related to it will be evaluated and executed to get a value, which may then cause other questions to be triggered also. It creates a cascading effect that may be out of order to the question order in the form.

With metadata questions (such as username,email etc) and hidden questions, these are loaded and populated at a different stage at startup as they are not visible, they only contain data values in database and not visible UI components. It is possible that the value in one of these questions is being populated, but before the relevant expression on the group is run, which causes the value to be nulled. In your case the app and form is working as expected, these questions just need to be moved into a location in the form that are not interrupted or evaluated because they are connected to the relevant expression.

Regards,

Phil.

0 Kudos