1. What is the problem? Be very detailed.
Enketo doesnt work correctly if I go back and change answers.
I've the sequence of questions below
Id10188
Id10190_units selected(${Id10188}, 'yes')
Id10190_a ${Id10190_units}='days'
Id10190_b ${Id10190_units}='months'
I answer yes to Id10188 then Id10190_units shows up.
I answer days to Id10190_units then Id10190_a shows up
I realise I made a mistake and go back to Id10188 and change to No.
Id10190_units is not showing up anymore but the answer I gave to it before "days" is still there somehow.
Then Id10190_a shows up even if know Id10188 is no.
2. What app or server are you using and on what device and operating system? Include version numbers.
ODK Central 1.3.2 abd Enketo 3. What you have you tried to fix the problem?
4. What steps can we take to reproduce the problem?
see above 5. Anything else we should know or have? If you have a test form or screenshots or logs, attach below. enketoerror.xlsx (36.0 KB)
Unfortunately there's little you can do here. When you go back and change your first answer, you are changing the results of the relevant field, which will now hide the second unit question, but will never reset it.
The answer will still be there, and as a consequence, the 190_a question will still be shown.
The two solutions you can apply are:
Change the relevant to ${Id10190_units}='days' and selected(${Id10188}, 'yes')
Put boh questions 190_a and 190_b in a group, and add a relevance to the group on 10188
In essence, the relevance of 190_a/b should be also on 188
Thanks for reporting this Aurelio! I have just noticed this behaviour on a small form I started developing for in-country data managers to send queries and where I had to add groups/complexify the logic as a quick fix to make the flow work on Enketo as it would on Collect.
I guess this would be a bug in the new release? I have a very long online survey, which I had tested pretty intensively back in March-May (with lots of back and forth in entries), and I think I would remember if Enketo had this behaviour before.
This is reproducible in Enketo 2.7.3 which was in Central v1.2.x. I believe this is a deviation from Collect that has always existed, unfortunately. I vaguely remember @Xiphware exploiting the Enketo behavior to use repeats as hidden loops to aggregate values or something like that. I think it's more expected that values which are not relevant are inaccessible for computation. I'd like to bring Enketo in line with Collect on this point but that would break forms like @Xiphware's. For now I'd recommend following @Mtyszler's recommendations if you're across the two clients.
If you really think it's a recent regression, we'd need help identifying a version of Enketo that does not use non-relevant values in calculations.
Yup. I was (rather) hoping to exploit repeat groups to perform enumeration calculations over a list [aside, see ODK geofence (v1)] but hiding the fact I was abusing them - as a quasi for(...) loop - by hiding them behind a relevant=false... Alas, making the repeat loop irrelevant caused the internal calculation not to be executed. Oh well, nothing ventured nothing gained...
to followup, although the XForms spec is a little vague on this, eg
6.1.4 The relevant Property
...
Description: indicates whether the model item is currently relevant. Instance data nodes with this property evaluating to false are unavailable in the user interface and can be removed from submission serialization.
which is all around displaying UI elements based on relvant=true vs false (and removing them from the submission data...), but it does go on to state:
...Elements other than form controls may also use a single node binding that selects a non-relevant node, but such elements are not made unavailable or non-operable due to the single node binding because it is not a UI binding expression. For example, actions such as 10.2 The setvalue Element and 10.16 The message Element or the 11.1 The submission Element remain operable if their single node bindings select a non-relevant node.
which, again, isnt terribly specific about what to do with actual (embedded) non-relevant calculations per se, but does kinda allude to stuff that is not specifically UI controls (which calculations could be considered?) as not nececessarily being disabled by their relevance, inherited or otherwise.
But that said, I dont have any strong religious views [although it would be nice to have some mechanism to process lists in XForms/Collect/Enketo...], and I do always agree that Collect and Enketo should behave the same regardless.
@LN
sorry I think there is some confusion here.
My original post was not mentioning calculations but simple relevancy skips.
In my sequence above.
I have my first question (yes/no option)
I answer "yes" to 1st and then I've my 2nd question that is relevant when answer to 1st question is yes.
This second question has option day/month.
I select days and then another question is asked according to relevancy.
Now I'm at the third question and I realise I made a mistake,
I jump back to question 1 and says "No".
Second question according to relevancy is not shown then, but the value selected for question 2 in the first flow is still there even if question 2 now is not showing up for the relevancy.
This means that question 3 shows up even if should never show up according to the relevancy.
Is that clearer now?
You can verify it with the form attached on the first post.
@aurdipas I got you! All expressions including relevance expressions follow the same evaluation rules. In Collect when a question is not relevant, its value is treated as blank for all expressions it is used in, including relevance. That leads to the behavior you and I expect with your form. In Enketo, if a question is not relevant, its value is still available to be used in expressions. That’s the behavior you describe. I’ve confirmed this behavior back to Enketo 2.7.3.
@Xiphware thanks, that’s what I was remembering! And thanks also for digging out the W3C spec. For better or worse, we can’t change Collect’s behavior, there are too many forms that take advantage of this existing property. It’s likely changing Enketo’s behavior wouldn’t be too disruptive but I don’t know how to go about confirming that.
@aurdipas, thanks for making the verbal autopsy form public and including a nice changelog. It is now part of the test suites for both Collect and Enketo. You probably don't need to verify that one any further.
