restrict list choices in a repeat's "select one" question based on choice selected in a previous repeat
Hello-
I have a sign inspection form that incorporates cascading selects across three nested repeats. Depending on the type of inspection selected (which corresponds to the type of structure), the user is provided a filtered list of structural elements. Depending on the element they then select, they're provided a filtered list of relevant element defects to assess.
Although the cascading selects work just fine, and the form also locks the number of repeated element and defect records depending on the previous selection, I haven't yet figured out a way to prevent users from accidentally selecting either the same element or same defect twice.
I do have an "assessed defects" checklist question (read-only "select_multiple" question, uses the join() function) visible for each element:
... and a similar "assessed elements" checklist for the entire inspection itself, but this method still requires user oversight, and if an element or defect is repeated, I don't know how to indicate to the user specifically which choice was erroneously selected twice.
Is there a way to remove options from the initial "select one" questions for subsequent repeated records based on what's already been selected? That ability would eliminate this possibility for user error and ensure that each element and their corresponding defects are assessed only once.
Thank you for any assistance!
Galen S.
Minnesota Dept. of Transportation
Ah, I must have misunderstood that other post then. I thought I read that the method breaks if user clicks back through any already entered repeated records.
However, I'm testing another possible method at the moment that looks promising; I'm using each choice/type's expected position (index) in the repeat list inside the choice_filter expression so that for every repeat, only one unique choice is available.
I'm not sure if this would be workable for a choice list as long as yours, since I had manually assign the desired repeat index values to every individual choice for our first and second level repeats:
... but that wasn't particularly burdensome, since our longest choice list is only 193 items.
But it seems to work! The one potential obstacle we've identified so far is that the position(..) function that actually populates the stored index values for each repeat seemed to be a little unpredictable during some previous testing, but I think I may have solved that by having the two nested repeats appear at specific times using Relevant expressions.
