Quick tech call: rectifying current() in choice filter

We sometimes organize informal calls on Slack to discuss a quick dev issue. This time I wanted to try a slightly more formal approach to make sure anyone interested sees it. Anyone working on improving ODK tools is welcome to schedule this kind of call as they find useful.

I'd like to discuss how to support choice filters in repeats. This has been a long-standing limitation and results in support questions such as the recent When I try to filter choices in a repeat, why do I get a type mismatch error?. The answer should be to use a relative XPath expression in the filter but Collect/JavaRosa currently doesn't interpret current() correctly. Details are at https://github.com/opendatakit/javarosa/issues/293. The eventual goal would be for XLSForm to output those relative expressions by default as discussed at https://github.com/XLSForm/pyxform/issues/4 (@Ukang_a_Dickson even has code ready to go for this).

Rough agenda:

Plus, you get to hang out with @dcbriccetti and @ggalmazor who have already said they're interested in joining me on this JavaRosa adventure.

One thing that would be extremely helpful to get from the call or on this thread is examples of forms that use current() today. We would use these in tests to make sure behavior is consistent where it is currently correct and to decide how to communicate and help users recover from depending on the bad behavior. @Ukang_a_Dickson would it perhaps be quick for you to see roughly how many Ona-hosted forms use expressions with current() and is that something sufficiently generic that you could share the order of magnitude (1000s, 100s, dozens, none).

Join the call at https://www.uberconference.com/opendatakit


In one current survey (~2500 lines in the xls form definition) we use current() 159 times, including in 13 choice filters within repeats. This is an example of our choice filter usage:

hm_category > 0 and hm_category <= ${hmnum} and hm_category != current()/../t_mhhsched_linenum

I can't make the call but I hope that helps.


1 Like

Thank you @Jason_Ives, that's very helpful! What client are you using? It doesn't look like stock ODK Collect unless current()/../t_mhhsched_linenum is going up two levels. Where is t_mhhsched_linenum relative to the node the choice filter is used in? Are they both directly in a repeat? Or is the select with choice filter in a group that t_mhhsched_linenum is not in?

If you could share another couple of examples of where you're using current() and why, that would be very helpful. Where did you come across this technique?

It is the standard client, although an older version (1.4.5 build 1048).

You are correct, current()/../t_mhhsched_linenum does represents a reference to a value in the repeat that contains the repeat with the choice_filter, so no they are not at the same group/repeat level.

An analogous usage where they both sit at the same level would be:
hm_category > 0 and hm_category <= ${hmnum} and hm_category != current()/t_fhhsched_linenum

These both function to exclude the current interviewee from the choice-list of household members.


Great, thanks. The bug is that those expressions are off by one step. The first should really be current()/../../t_mhhsched_linenum and the second should be current()/../t_fhhsched_linenum. current() is always supposed to represent the node that the expression is found in so there should always be a first ../ step to go one level up from the current node. It sounds like you're not upgrading clients so this change won't affect you. If you were to upgrade Collect at some point, you would need to update your forms.

I'd be very interested in knowing how you started using this. Was there a forum post or some documentation that led you that way? Do you happen to know XPath? ...? That will help us get a sense of how common it might actually be.

1 Like

Right, we identified the issue and work around it. We are testing to upgrade to 1.15.1 now, we previously tried to upgrade but detected a critical failure that has since been fixed. We are prepared to update our code if necessary, although that obviously would be in a future update, not the one we are testing now.

Regarding where we picked up the technique, Mitch has posted about using current() a few times, and there have been discussions on the dev side about this functionality as well. I guess it is that along with trial and error. Honestly it is hard to pin it down, we've been using current() as necessary for several years.


Thanks, all this information is very valuable. We'll definitely make sure we provide lead time and communication when we finally do make the change.

The devices we verify each release on and the manual smoke test each goes through are described at https://github.com/opendatakit/collect#contributing-testing. If there are cases you are verifying that are not on there it would be great if you could share your process and results. In general, please do share any issues you run into so they can be addressed in a timely way!