restrict list choices in a repeat's "select one" question based on choice selected in a previous repeat

[Galen_S_MnDOT]

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

[Galen_S_MnDOT]

Thank you for the example!  I ended up taking a slightly different strategy.  Instead of trying to detect and prevent duplicates, I used a choice filter expression that incorporates the index values (i.e. "Position") of our repeated records, and only allows one at a time to be chosen, and in the proper order.  Ultimately it still enforces that rule that each potential structural element is only assessed once, and each defect relevant to each element is likewise only assessed once.

This version of our form is still in development, but initial testing seems to indicate that our method works consistently.  Of course we still run into problems sometimes when beginning new inspections entirely or trying to resume an existing but incomplete inspection from a draft (or crash-recovered entry), but most all of those problems seem tied to known bugs with the "repeat_count" parameter and not this specific use of choice filters.

Looking forward to digging into your example more as soon as I'm able!

[DougBrowning]

If you have not tried the 3.14 beta yet I would.  There are major changes to repeat count that fixed and also broke some stuff in ours.  Draft and repeat count still has issues for sure.

I have found that in some cases repeat count just wont do it.  So instead I use position or count in a constraint.  This way it grows the repeat up to a point vs loading the whole thing at once.  It can get you around a lot of issues.

Good luck