Hi ODK Forum! I'm hoping someone can help me with the following issue.
Background Information: We have built a beneficiary registration form, which includes a repeat group to allow our staff to register multiple people in one instance. Within the repeat group, we need to collect the location of each beneficiary's home - this is done using a cascading select. This is using XLSForms, the Ona Server, and ODK Collect application.
The problem: As I am now aware, using a cascading select within a repeating group causes issues after the first entry. I would like to find a way around this as we need to collect this information about each beneficiary registered in the form. I have already gone through previous threads in the forum, as well as searched a variety of online tools and guides, and I believe that this may be possible by using the indexed repeat function, but I am still unclear on how I can actually apply the indexed repeat in this case.
Support I am looking for: I am looking for a way to make this form work without changing the structure of the form much, or at all. As this form is already live, and collected data is already being forwarded to a PowerBI system, a restructuring would really cause some issues. If indexed repeat is the only solution, I am looking for support on how to integrate that function into this form, as it is my first time using that function and it is a bit over my head at this point.
Welcome to the ODK forum, @Kate_Seong We're glad you're here. When you get a chance, please introduce yourself here. I'd also encourage you to add a real picture as your avatar because it helps build community!
Please find attached a modified version of the form. Additionally, since you have a long list of the administrative units, you should try to use an external csv file.
What other issues are you experiencing with the form? A little more information will help me to help you better. Have you tried the version I sent you as attachment? After the modification, I checked that for and the issue you had previously is not present anymore. I noticed that you are trying to use dual language option and you need to make some changes on that.
Hmmm indexed-repeat shouldn't be needed her at all. Looks strange I tried to use indexed-repeat anyway but it didn't help. looks as if there is something special if we use choice_filter.
Use this link as trial. Trying to understand what is expected behavior of the form if "Registered Attendance" is select and what if "Mass Attendance" is selected? Attached the form I converted. I think you simply have some logical issues.
Cascading selects within repeats require using current() to specify the filter you want to apply. If you have a first variable named city and a second one named neighborhood, your filter for the neighborhood would contain something like current()/../city. Unfortunately, there's a bug in Collect that makes this fail. current()/city does work now but it will be changed in the next release (likely late October or early November). You can read more at Quick tech call: rectifying current() in choice filter.
If you absolutely need to use this now, you can use an expression like current()/city. Every time that question is answered, you will get a dialog warning you about the impending change. You will need to change your forms for them to work with the next version. More about the dialog at Collect: Use of current() in a choice filter.
EDIT: here's a bit more context, especially for @Grzesiek2010:
XLSForm allows us to access fields within a form with special ${} syntax. It expands this to an absolute path so something like /data/my_repeat/my_variable. If ${} is used to refer to a variable within a repeat, that's a problem because there's an ambiguity about which repetition's variable we want to access. When Collect runs into that kind of ambiguity, it throws up that message about using indexed-repeat().
In most cases, using indexed-repeat can solve the problem as it's just a wrapper to produce the XPath syntax that gets us to the value that belongs to a specific repeat (e.g. /data/my_repeat[7]/my_variable[1]).
When we use a choice filter, that's actually an XPath predicate. That means we end up with something like /data/my_repeat/neighborhood[city = ...]. In that predicate, . refers to the predicate itself. So to refer to a question that is a sibling of the question that has a choice filter, we need to use current(). current() refers to the node that has the predicate (e.g. /data/my_repeat/neighborhood).
We could use choice filter in this context, but we run into the same problem as I described above -- to get the position in the repeat, we'd have to do position(current()/..) and that is affected by the same bug.
Okay, so the repeat should not come up if they are selecting mass attendance. If mass attendance, we have separate questions, which I omitted from the sample because they are totally separate from the repeating group.
So, the only time that we want to ask "How many people are you registering at this time?" is when there is a registered attendance (they selected registered attendance in the attendance type question).
I don't think that's a logic issue, because the repeating group itself has been working with no problems. The only issue is that the location cascading select is not working within the repeat.
That's really great information for me, thanks so much for sharing.
I am super new with this so please bear with me! I have 4 levels of cascading select here - we'll call that district, subdistrict, village, and subvillage for now. As an example, I'm using the following in my choice_filter column: district=${Participant_District}. So, when using current(), does this mean I would input "current()/district=${Participant_District}" or "district=current()/Participant_District" ? And as I move through the levels, the same applies?
You've got the concept! The second expression you mentioned is exactly right for Collect 1.17 and older. Again, just understand that this behavior will change in 1.18 and that you'll need a ..!!
In more detail -- for subdistrict, provided that you have a question named participant_district that is in the same repeat and a column in your choices sheet called district, district = current()/../participant_district is saying that you only want subdistricts whose district column in the choices sheet matches the value entered in the participant_district question. current()/../participant_district means "start with the current question, go up one level to the repeat and then select the participant_district question. But due to the bug I mentioned, Collect now expects district = current()/participant_district, just like you said.
And like you say, same concept for the others. If you have a subdistrict column in your choices sheet and a participant_subdistrict question, you'd filter village with subdistrict = current()/../participant_subdistrict (and adjust for the bug).
I'm wondering now whether in the new version, current will still be required if I use an external select rather than a cascading select (internal) inside the repeat group? We are thinking to make the shift at the time of the update, but not sure if this will create the same issue? If anyone has any ideas on that, please let me know!
current() is part of the expression that lets you get to the answer you want to use as a filter. So yes, you should use it in your choice filter expression for an external select in a repeat as well. In that context, the correct approach with .. that looks like current()/../question_name works today and that won't change with the next release.
(I say "should" because technically the external select implementation is an odd one and that's why it's not affected by the bug we're fixing. But please do treat them the same way as internal selects to ensure the best compatibility and most consistent mental model.)
hello ,
I had that issue too and that solution works. It works in collect but when I open the form in enketo the select list is empty.
Please, your advise is welcome. Thanks in advance.
When you see that kind of behavior, it works in collect but not in enketo, means that feature it is not available in enketo. Can you share that part of the form, you may get more assitance / advice if available.
