Fixing current() context in choice filter

As was discussed at Quick tech call: rectifying current() in choice filter, there is a bug in the implementation for current() in choice filters. The implication is that forms that currently have a choice filter that includes current()/ will need to change their expression to current()/../.

The Collect 1.16.1 release from July 26th added analytics to track how common this usage is. Between July 26th and August 13th, 19 unique forms used current() in choice filters. Because we didn't want to compromise user privacy, we have no way of identifying what those forms are or who they are used by. The top 6 forms have displayed choice filters with current() 200 to 1000 times in this time interval.

For reference, in the same time interval, 1,810 forms including choice filters without current() were used. The top 6 displayed their choice filters between 12,000 and 21,000 times.

The good news is that relatively speaking it's not a ton of forms that will be affected. The bad news is that these forms are in active use so there will be some disruption.

I'm not really sure how to get the word out to users that this change in functionality is coming. Any ideas?

I think some :clap: applause :clap: is in order here. This is a very clever approach of measuring the impact of a change without compromising user data. It's a technique that will prove very useful in the future, so nicely done.

I'd propose we do the following.

  1. In the next release (v1.17), we add a toast on form load that warns users that form behavior will change in the next release and so they should ask their supervisor to update their form or disable Collect updates until they do. We can link to a topic on the forum to make sure.
  2. In the release after (v1.18 and greater) we change the behavior of current and add a toast that says the form behavior has changed and that the form is broken in whatever ways. If we could temporarily enable the old behavior (I'm guessing we can't), then we'd give them the option to toggle for that form load.
2 Likes

I have a pull request up to do this at https://github.com/opendatakit/collect/pull/2524. The dialog is shown on every affected question and looks like:

Please let me know if you have any suggestions on how to make the text even clearer. Tapping "Read details" will open up a forum post with recommended actions (coming soon). Tapping "Continue" lets the user continue filling out the form as normal.

There have now been 44 unique forms with current() in a choice filter logged since July 26. In the same time interval, there have been over 4000 forms with a choice filter without current(). So it continues to look like this won't affect a ton of users.

I went back and forth on whether to add a "Do not show this again" checkbox on the dialog. On one hand, this will get annoying to enumerators. On the other, we really don't want anyone to miss it. If we make it possible for the dialog to be permanently dismissed, it could be hard for users to find the information again. What do others think?

How about not showing "Action needed" message if form is using current()/../? or at least adding "Do not show this again" if form's using current()/../?
EDIT. My form doesn't work properly with ODK Collect v1.17 if I use current()/../ instead of current() in a choice filter ).

1 Like

It's tricky to do these kinds of substitutions because current()/../ has meaning in both versions, just not the same one! That is, in Collect v1.17 and before, the bug means current()/../ refers to the group two levels up from the select question but in Collect v1.18+ it will correctly refer to the group one level up from the select question. It's difficult to guess what a form developer intended.

If a lot of users were affected by this, we could add a way for form developers to indicate what interpretation they want but since we were able to measure that a really tiny number of forms use the technique, we will fix it, document the correct way and make sure more form creators have access to this powerful way of building relative expressions from choice filters.