Field validation depends on order of fields - is this intended or a bug?

Support
, ,
1

What is the problem? Please be detailed.
I have validation which considers 2 different fields on the same page of the form.
If I have the fields appear in one order, the validation works as expected.
If I reverse the fields order, the validation does not work properly (it appears as though the calculation inputs are not refreshed)

What ODK tool and version are you using? And on what device and operating system version?
Collect 1.10.2 (this is not a new issue - I have seen it in the past on previous versions)

What steps can we take to reproduce the problem?
Make use of the files attached below

Start with test_form_logic.xml
Attempt to swipe through without changing anything - it should give a validation error.
Now change the "Yes" to a "No", and attempt to proceed - it still gives an error (although according to the logic it shouldn't!)
Now leave this as a "No", swipe back to the first page, then forward again to the end of the form. Now you are allowed to proceed to the end!

Repeat the steps with form test_form_logic2.xml
For this form it works as expected. The only difference is the order of the fields.

Anything else we should know or have? If you have a test form or screenshots or logs, attach here.
Test files:
test_form_logic.xml (2.4 KB)
test_form_logic.xls (44 KB)
test_form_logic2.xml (2.4 KB)
test_form_logic2.xls (44 KB)

1 Like
2

Just a note (although it doesn't affect the initial question at all):

The direct time comparison doesn't appear to be reliable:
.>${time_start} or ${time_end_on_same_day}='no'

You need to use decimal-time():
decimal-time(.) > decimal-time(${time_start}) or ${time_end_on_same_day}='no'

3

I'm more surprised by the behavior of the second form than of the first! Calculations, relevants and constraints are NOT reevaluated within a field-list. I'm not sure where this is documented and it is a really unfortunate limitation. The good news is that @jamesknight is looking at it currently and you can track that progress at https://github.com/opendatakit/collect/issues/378

When you swipe back to the first page and then onto the page with the field list, you're forcing a reevaluation. I would expect the second form to require the same and I don't have a good explanation for why the order matters. Since that behavior will improve soon, I'm thinking we don't need to look too deeply into it (though @jamesknight, it may reveal some strange implementation related to the improvements you're making).

4

The field-list gotcha is currently documented at https://opendatakit.org/help/form-design/workarounds/. @adammichaelwood can you fill an issue to pull these into the docs? It might be a good task for some of the more experienced Outreachy folks to take on.

5

Thanks @LN and @yanokwa for clearing that up. I was aware of the field-list limitation on relevant which makes sense, but had expected the constraint to only be loaded/calculated when the swipe to next page happened.

Have subscribed to the linked issue, thanks, glad someone is working on it!

1 Like