Dynamics repeating groups error

[akselhmadslien]

Description of the bug

Values in the first repeating group affects the readonly and required properties of the second group

Steps To Reproduce

1. Clone the repository https://altinn.studio/repos/krt/krt-1230a-1
2. Start the app and log in as Sophie Salt
3. Go down to the repeating group "4 Forsikringsforetak som agenten formidler forsikringer for"
4. Click "Ja" on "4.1 Har forsikringsforetaket et norsk organisasjonsnummer?" and add a second group
5. Click "Nei" on "4.1 Har forsikringsforetaket et norsk organisasjonsnummer?" in the second group
6. Change the value of "4.1 Har forsikringsforetaket et norsk organisasjonsnummer?" in the first group and see that the field "4.5 Ev. annen ID" in the second group changes readonly and required status

Additional Information

Changing (1) should not affect readonly and required status of (3)

Link tt02: https://krt.apps.tt02.altinn.no/krt/krt-1230a-1/

Link to layout json: https://altinn.studio/repos/krt/krt-1230a-1/src/branch/master/App/ui/layouts/Innsending.json#L355-L575

[olemartinorg]

Sadly, this looks to me like it's caused by your component IDs clashing with our internal state-keeping in app-frontend. When in a repeating group, a component can appear multiple times (i.e. have multiple instances), and for some reason we keep that state inside a mutated component id, in order to keep component IDs unique across multiple groups. So, if you have defined a firstName component, it gets the id firstName-0 in the first group and firstName-1 in the second group.

This is documented in detail here. When you've chosen to name your components like 4-5 and 4-5-1, app-frontend looks up the component 4-5-1 and finds it in the first group, as it's ambiguous if you meant the component 4-5-1 or 4-5 in the second group (which also has the generated id 4-5-1). The first one to be found here is probably the component in the first group, meaning your expression that should be evaluated in the context of the second group is actually evaluated in the first group (as that is where the first instance of your component ID was found).

This is part of the reason why I want to create a validator, as described in #648 (see As long as app-frontend-react puts the repeating group indexes into the component ID, we should show warnings when component IDs could be misunderstood as having repeating group indexes (i.e. matching <something>-<short number>)). Yes, this is a code smell. Yes, we want to fix this. No, it's too ingrained in how app-frontend works in regards to repeating groups right now to really fix properly right now, and we'd like to fix this once and for all in something long-term, like #345.

For now, I suggest (as I believe I've suggested before) that you name your component something else that does not clash with our internal state. Sorry!

[ivarne]

I agree that the long term goal would be to not have these kind of requirements on user supplied ids. Would it be hard to change the "reserved" suffix from -{index} to -internal--repeatingGroup#{index}? Seems like that will make this kind of clashes much less likely, and work great as a stop-gap-messure.

[olemartinorg]

@ivarne Sadly, yes, that would be hard. It's mostly about test coverage and safety (i.e. try search-replacing a single dash in the entire codebase and make sure you caught all the code paths that used a dash for this thing). It could absolutely be a short-term solution, but right now it's much easier to just change the component IDs. I belive this wasn't caught as a likely problem, since Studio always used to generate long UUIDs as IDs at the point in time this was first implemented.

[olemartinorg]

In #758 I try to indicate which component IDs are problematic via the regex in the layout JsonSchema. I hope this will be somewhat helpful, at least!