Editing records with repeats based on # of select_multiple is causing problems (web app version)

[MaryGraceMcClellan]

The survey I've created is using a formula to generate the repeats based on how many answers were chosen in a previous question. The repeat_count formula looks like this: 

count-selected(${projects})

Then, within each repeat, I am pulling out values ("project_name" in the example below) from the select_multiple based on the repeat index, like so: 

repeat_index = position(..)
project_name = selected-at(${projects}, ${repeat_index}-1)

It works really well when the survey is first being created, but the intention is to go back and edit the records through an embedded version of the survey in an Experience Builder. The issue I end up with is, as more projects are selected, the indexing gets messed up and the values are inserted based on where they are inserted into the list.

For instance, the first item might be "PROJECT3", and all the relevant details are added to the first repeat for that project. Then, the user goes back to edit the record and adds "PROJECT1" to the select_multiple answers. Now the first repeat still says "PROJECT3", but so does the second repeat. So then I recalculate the first repeat and it does become "PROJECT1", but the details are all mixed up now. 

I hope this is making sense! Has anyone seen this behavior and come up with a good fix? I've found that some fuinctionality (such as calculationMode) that might be helpful is not available in the web app version of Survey. 

[abureaux]

I believe that this can be calssified under "known functionality". Basically, you have two related issues.

1. When a repeat item is deleted, the index(..) gets messed up
2. When working with calculates within repeats, the calculates only fire for the currently active repeat item. If you manually scroll through each repeat item, the calculates will re-fire. If they don't (and you manually scrolled through the repeat items), then you just need to add calculationMode=always to the calculate.

[DougBrowning]

I have found that changing repeat_count on the fly wipes the data.  Not sure if this is what you are seeing but repeat_count really does not like being changed.  Also it loads all the repeats at once which messes up a lot of calcs.   It got to the point where I stopped using it and instead use count() in a constraint.  It is just way more reliable.  Hope that works for you.

[KristinThorpe1]

Hi @MaryGraceMcClellan! Any work around to this? Is there a way to store the selection value in a text field or something in the order in which it was selected? I have a similar issue with using a select_multiple value in a repeat field. I want the Phase field to equal the index of the selection at the position of the repeat. Except if the  selections are not made in choice order, the value at n position is constantly changing. 

[DougBrowning]

You can put a once() around the position then it will not change as you navigate.  Be careful with position though it has been causing lopping issues.  Watch in connect to see if it comes up and warns you after a few minutes at the mid top right.  Instead I went back to the old way of having a hidden field with a calc of 1 then using once(count()).

Hope that helps

[KristinThorpe1]

I always forget about once(), but I don't think it is the solution I need. Let me try and explain a little better.

I believe my issue lies with how the values of select_multiple questions are stored. In the web app, the selected choices follow the order of the choice list, not added at the end of the list like in Connect. For example, I selected CD1, CD4, and CD99 in that order. If I then select CD2, CD2 is added in the second position of the list instead of tacked on to the end like in Connect.

I want to use the choice selection at n as the Phase value in my repeat at record position n. This works great, until a choice is selected out of choice order (i.e., CD2). I have a count-selected() expression on the repeat count field so the number of repeats equals the number of selected choices. So I think what is happening is when CD2 is selected, a fourth repeat record is added but now the fourth choice in the choices list is CD99, which was the third choice in the list when there were only three choices selected (and, therefore, only three repeat records). What I need is for the selection to store values in selection order like the field apps. This is logged as BUG-000162103 but I'm hoping for some kind of workaround. Thanks!