We have encountered an issue where a unintended duplicate multi select dropdown component is rendered to the screen.
What the form is attempting to accomplish:
The non-profit organisation should define if they operate in a ‘rural’ or ‘metro’ area.
Based on this selection the ‘district’ multi select dropdown that follows will have its location cascade values filtered appropriately.
A ‘municipality’ multi select dropdown is conditionally shown depending on if the operational area was deemed as ‘rural’. It will have its relevant location cascade values filtered by district.
The ‘main place’ multi select dropdown that follows will then either belong to a ‘municipality’ or linked directly to a ‘district’ based on the type of area selected. It too will have its values filtered accordingly.
Lastly a ‘sub place’ multi select dropdown must be completed, which belongs to the ‘main place’.
This flow is followed for each selection made in ‘district’, ‘municipality’ and ‘main place’.
Eg. For each ‘district’, select the relevant ‘municipalities’ and then for each ‘municipality’ select its ‘main places’.
Thus, it requires a 3-tier level repeat structure in order to satisfy the needs.
For the ‘rural’ flow everything works as expected, the ‘metro’ flow however has produced the bug mentioned (see screenshot).
To test this further, a note was added before the problem ‘main place’ dropdown (named sm_municipality_main_places) as well as after it.
It remains the only component that gets unexpectedly duplicated.
We also checked the generated xml and there seem to be only one entry with that name (see screenshot).
I’m unable to share the xlsx file here, but it is available if required.
What version of the CHT are you using? There are some known issues with repeat groups in CHT 3.x that have been fixed in 4.0. I am not sure either of those issues cover your exact case, but suffice it to say we have seen some weird things happen around repeats.
I wonder if the issue would still present itself if you were not using repeats. It is hard to be sure without seeing your actual form logic, but I wonder if you need the repeat at all, or if you could achieve your desired behavior with cascading selects? Cascading selects can be implemented via relevant
and choice_filter logic. See the “Cascading Select widgets” section in this example form.
Beyond this, it would be super helpful to have access to some version of your form where we could try to re-create the behavior. Thanks!
Good day @jkuester,
Thank you for taking the time to get back to me.
We are currently using version 4.1.0. Unfortunately, none of those issues seem to apply to our current scenario, and neither does the fixes.
What were some of the other weird behaviours regarding repeats, and are they still present in 4.1.0?
Would this be an ODK level issue, or would it be more on the CHT side itself?
Please find the latest version of our form here.
For clarity, this is the highest level ‘contact’ form in the ‘place’ hierarchy.
We are currently using a cascade select approach in order to filter the values for each of the district, municipal, main place and sub place multi select fields.
I am unsure if we would be able to satisfy our requirements without utilizing a repeat structure. The location selection is completely dynamic, and its available options will be quite vast going forward.
We have several cases where we require the usage of repeats, for instance:
Visitation repeat on each household (which is our lowest level PLACES entry).
Grants (eg. Type [Child, Disability, Education], date), Births (name, alive, born, etc) – Individual actions (on a person)
Could you perhaps provide an example of a multi-level repeat, or put us in touch with anyone who has used it?
Any guidance would be greatly appreciated.
Well, I was able to recreate this issue!
The bad news is this is definitely a bug (one that I had not seen before) in Enketo (the ODK library that the CHT uses). I have logged this issue with the Enketo team. You can follow that for more details/updates!
The good news is that there seems to be a pretty easy workaround (as long as it is acceptable for your use case)! On your form, the sm_municipality_main_places field is the one being duplicated. It is a select_multiple question with the minimal appearance. Removing the minimal appearance from this field caused the issue to go away for me. (All of the choices were then displayed as a checklist on the page, but they were not duplicated.)
Let me know if that workaround is not going to be sufficient for your needs and we can look for other ways to structure your form to avoid the nested repeats…
Thank you for looking into this!
I appreciate you following up with the Enketo team themselves.
It’s unfortunate to hear that a fix for the issue will be delayed at this time.
Thank you for the workaround suggestion! On initial glance it seemed to work great.
Unfortunately, I’ve noticed some irregularities persisting.
To recreate:
On the first screen select ‘rural’ for the location type, and both available districts.
On the second screen (Local municipality selections) be sure to select all the available options.
On the third screen everything seems to display and work as expected.
Now navigate back to the second screen (Local municipality selection) and only select 1 item on each of the drop downs.
Move on to the third screen again where you’ll notice that the 2nd district repeat block ‘washington’ now has empty values even with the ‘minimal’ appearance change (see screenshot).
I presume this is, as mentioned in the github issue, due to the recalculation of the repeat_count?
In addition to the above issue, I’m worried that a plethora of checklist items for both the ‘main place’ and ‘sub place’ directly beneath each other on one screen might be confusing to the users.
Perhaps if the ‘sub places’ are displayed on another screen for each of the ‘main place’ selections.
Though that does not address the repeat issue we’re currently facing.
Yeah, sadly I am not too surprised that going back and changing things in the dynamic nested repeats ends up resulting in weird behavior. It is possible that you might be able to solve this behavior by tinkering with your field-list configuration (changing pages in the CHT does sometimes help force-recalculate things), but given all the other weirdness with nested repeats, I would be nervous about building to much complex logic into them…
That being said, I still wonder if it would be possible/preferable to try and flatten your logic to avoid the nested repeats altogether. Have a look at this simplified proof of concept form. Basically it supports the multi-selects you need for defining your hierarchy (pick your districts → for each district, pick municipalities → for each municipality, pick main places…). The key difference is that with this form, you make all of the selections for a particular level of the hierarchy before moving on to the next level. This allows just having a single repeat for each hierarchy level and no nesting. (The “magic” here is to use concat to build out a list of all the locations selected in the repeated select_multiple question. Then, this list feeds the next repeat in the sequence…)
Thank you so much for taking the time to write a detailed response and providing the flattened structure file.
While using the concept file, as is, I found that:
Selecting all available districts, municipalities and all main places for some reason only yields 4 sub place items on the last screen (the last 4 selected on the main places screen).
I’m unsure why that is the case.
I ended up using the join approach used in the original file sent, together with the flattened structure approach - which seemed to work for the most part (see here).
However, as soon as I introduced the dynamic main place count again (either using the district or municipality count based on location type), things start to act strange.
This issue can be recreated by doing the following:
Select Location type = rural.
Select all districts and move on to the next page.
Move back to the original page, change Location type = metro.
Select all districts again and move on to the next page.
It seems as if the position method becomes confused and starts with a higher index (see attached).
It shows that 2 items are available for selection, namely ‘metro1’ and ‘metro2’.
Note: The map & mapping fields are used for data persistence and potentially cascade choice filtering.
Ah great call on the join! I have updated my form with that so I remember how that works in the future!
The new behavior you have described here is super weird. I have been able to recreate it, but even after several hours of tinkering, I have not been able to pin down an exact cause. It appears to be some kind of weird interaction in the re-calculation logic for the repeat_count. Basically bad things happen when the repeat_count gets (temporarily) set to 0 because of the recalculation of a choice_filter in one of the dependent fields. As you noted, it seems like some of the internal state of the repeat is not properly reset in this case and things get out of sync. I was not able to re-create this behavior in the latest version of enketo-core (the ODK library used by the CHT) which leads me to think that this issue has been fixed in the 6.x+ versions of enketo-core (there are several changes noted in the release notes involving repeats and/or cascading evlautions).
We already have an open CHT issue to upgrade to the latest Enketo version and I have added a note in there to test this exact case to ensure it is resolved by the upgrade.
To work around the issue for now, one option I found is to avoid using the choice_filter for the sm_districts field. Basically I tried splitting the districts list into two separate lists (one rural and one not). Then instead of sm_districts I had separate questions for each list with relevance toggled based on is_rural. Finally, I actually kept sm_districts as a calculate that just was set to the value of one of the new questions (based on is_rural). The end result was the same values getting set for sm_districts, but no choice_filter (which seems to have eliminated the observed behavior…).
Thank you so much 
I’m glad to hear that the efforts expended was not in vain and resulted in possible fix being found.
Eagerly awaiting the new enketo-core integration.
Thank you for linking the related Github issue and making a point to test our current repeat problem.
What is the timeline for the updated core to be incorporated into main?
Coincidentally, the Github issue mentioned was opened precisely a year ago yesterday 
.
That is a great workaround suggestion, thank you, we will definitely give it a go!
In the interim, and for posterity’s sake, we have created a form that basically just duplicates the main and sub place structures for the district direct case.
It also seems to circumvent the current issue and can be found here.
Your workaround is much cleaner, we are keen to get that implemented!
I will be sure to edit the post with the updated file once it is done.
We appreciate all the effort that has gone into answering our questions and guiding us to a solution.
— Edit —
As mentioned I implemented the workaround, that file can be found here.
Unfortunately I could not get it to work without running into the same issue mentioned above, perhaps I’m doing something wrong?
Regardless, I’ll keep this file here for when the updated enketo-core is implemented.
For now I’ll revert back to the previous file in this post.
1 Like
What is the timeline for the updated core to be incorporated into main?
I don’t have any exact dates, but the current plan is to do this work in Q3 of this year.
Unfortunately I could not get it to work without running into the same issue mentioned above
Hmm, I might be missing something, but when using this form (the second one you linked) I cannot seem to re-create the issue. The repeat always had the proper entries even when I followed the original re-creation steps (select ‘rural’ for the location type, and both available districts, etc). The district names were not being properly displayed for the sm_district_direct_main_places question, but that was just because the district_ calculate had the wrong relevant condition (I think it should be ${is_rural}=0).
That did it! The incorrect check mimicked the behavior of the district not resolving like in the previous forms.
Everything seems to be working now.
Thanks a bunch for all the help!
— Edit —
The newest NPO create and edit forms.
1 Like
