Avoiding duplicate selection in repeat group

Thanks for this. The form is running perfectly but when you download the data, the database is empty. I dont know what could be the reason? I have tried a similar looped indexed types of questions but i am loosing data for the repeat groups.

1 Like

@Levie_Nkhoma, what server/platform (and version) are you using to gather the data?

Can anyone help me with this error?
I would like to avoid duplicate selection in the items list (row 15, survey sheet in attached xls) and tried as mentioned in repeat_groups_avoid_duplicates xls file by @Souirji_Avdelghani. But it didn't work and replied as invalid in constraint expression when the attached xls was deployed into kobo toolbox.
Could you please check in the attached xls form and help me with the correct expression in constraint for avoiding of duplicate selection to the items.
Thanks in advance.Kobo_Covid19 Response_test.xlsx (20.8 KB)

@mhl, You have a mistake in form name that used in your constraint, replace white space with underscore and it works.

2 Likes

Hi @A.N.M_AL-IMRAN, @Souirji_Abdelghani

Please have a look at the attached example, which is based on the case above of the letters A, B, C, D.

I used substring-after() to compare the duplicate values ​​with the selected answer in ODK.

I hope this file is useful.

avoiding_duplicate_selection_in_repeat_group.xlsx (12.6 KB)

Hi, I tried to use this same example, without making any modification and is not working. Do you know what could be the reason?
I am looking for a similar example where 3 select groups are nested in a repeat loop. First select age groups (<18,>18), then sex (male, female), then education (primary school, high school, university, etc), and finally an integer to account for the number of individuals having these characteristics. Any help is more than welcome!

Hi I am linking this in here as an alternative which worked for me. https://community.kobotoolbox.org/t/preventing-duplicate-entries-in-a-repeat-loop

This solution won't work if the full form is re-evaluated because the result of the join will include all values saved and the validation will fail for every question. Enketo seems to sometimes do a full re-evaluation but not always (this is something we intend to harmonize between Collect and Enketo at some point). Collect always does the full re-evaluation so the form will not work.

I believe this form works in all cases across Collect and Enketo.

1 Like

Thanks LN I will take a look and update.

Hi LN, this form gives an issue on save which is the earlier problem i was having. Give the error 'Sorry, this response is invalid!' which is why I looked for an alternative solution as i could not work out what the problem was. Please let me know if there is something i can update. It seems to always be on the second option on save

Thanks

Acá dejo un ejemplo más, espero que sea lo que buscan,

Detectar ID Duplicado.xlsx (13.9 KB)

Saludos

Hi LN, i have done some tests on this form (original link i posted) and it seems to work. What part would give an error - on save error, or would I get data loss/error occurring. It would help me to know what to look for.

Unfortunately I still cannot get the form you linked in to run correctly.

Regards

The form I posted was indeed in a really weird state, sorry about that. Could you take a look again? The important components are that there's a join calculation outside of the repeat that aggregates all of the values and then there's a calculation inside the repeat that takes that aggregate and removes the current choice from it:

concat(substring-before(${so_far_outside}, ${choice}), substring-after(${so_far_outside}, ${choice}))

For example, if a, c and d are selected, the so_far_outside string will be a c d and in the context of the third repeat, so_far will be a c which allows d to be selected. Similarly, in the context of the first repeat, so_far will be c d, allowing a to be selected.

I looked at the form you posted and I don't understand how it would work. I tried it quickly in Enketo and as soon as I put in three codes, no matter what they are, I get a failure when I try to validate. This is because the join expression includes the current question's code, thus making the constraint fail. Have you made successful submissions from that form? Additionally, the substring expression doesn't make sense because it's always removing codes from the end rather than removing the value corresponding to the current repeat. You can change the label for Q1 to So far: ${C3} to see the value that the constraint is being evaluated against.

Thank you LN, thank you for the time taken to write the explanation. I tested it and it was working until I selected a certain combination of option and then it gives me an error on save 'This species has been selected' (the constraint message).

I think this is because I am using numerical codes for the names, so I have a species of '7' and a species of '73' which is causing the issue, is this possible?

I would prefer not to change my ID codes to get around this, is it possible to modify the constraint to accommodate this?

Regards, Rusti

Yes, absolutely, that form does assume that each value is unique and not contained in other values. This is a reasonable assumption for selects but you're right that it doesn't make sense for arbitrary strings or integers.

This form shows an alternative using an XPath filter expression (the stuff in the square brackets):

join(' ', ${rpt}[position != current()/../position]/id)

That says to join all of the id values for repeats which are not the current one. I tend to try to avoid XPath in examples but in this case it may actually be a clearer solution all around and less risky because it doesn't assume anything about values entered. What do you think?

I didn't look at @bdra2778's example above in great detail but I think the concept works as well. It uses a parallel repeat to compare every prior value. Do note that it would be slower with a bigger repeat. @bdra2778 there also is one limitation I can think of: because your repeat count is position(..)-1, you won't immediately detect duplicates if someone comes back to edit an answer. For example, if they enter in 2, 6, 7 and then go back to change the 2 to a 7, I believe that will be accepted. However, on validation, the second 7 will show a constraint failure. This is not a big deal but I did want to point it out.

Hi LN, thanks again for your time on assisting me with this, I am an end user rather than a designer but I am learning slowly! I have implemented the Xpath you suggested and it seems to be working well, I'll be doing some more testing today to check on the issue you highlight, going back to change options is generally not an issue on the form I am working with though, but will check.

The alternative I was working on yesterday with your previous example was to create unique ID (a-z; 0-9) which is limited to 36 options, and then using a calculate field to change back to my database values. It would have worked for the form I am bust with as there are <36 select_one options, but going forward this may increase.

Thanks again LN and @bdra2778

Thank you for your guideline and supports

You're welcome!. I am glad my post still helps.

2 Likes

A post was split to a new topic: Hide choices in repeat group

A post was split to a new topic: Controlling selections in multiple choice