Repeating groups: Panel i repeterende gruppe lukker seg ved bruke av mapping på dropdown i samme gruppe

[StianVestli]

Description of the bug

ref : https://docs.altinn.studio/nb/app/development/ux/fields/grouping/alternatives/#vise-gruppen-som-del-av-panel
Hvis man benytter et panel i en repeterende gruppe som under , så vil panelet lukke seg før man får fylt ut alle felter hvis man har logikk i dataWrite som setter en verdi til et datafelt som er satt som mapping på dropdown i repgruppen.

I eksemplet over er det 2 rep grupper og en multiple select.
Selecten viser en liste med konflikter som vises i gruppe 1, disse er også linket inn i gruppe 2 i dropdown, da man skal kunne velge konflikter.
Multiple select og dropdown i gruppe 2 har da samme optionliste som datagrunnlag, samt det er satt mapping av at hjelpefelt på begge listene. Det er dette feltet som får satt en verdi i DataWrite slik at den "refresh" av dropdown og selecten skal skje.
Konfliktene i gruppe 1 skal kunne velges i dropdown i gruppe 2.

Som man ser lukker panelet seg når man har satt navn på ny gruppe.
Panelet burde holde seg åpen til lagre er klikket, kanskje burde den ikke sende data til backand før man faktisk trykker Lagre her, man burde og ha en avbryt knapp i panelet.

Steps To Reproduce

Kode for å reprodusere dette: https://altinn.studio/repos/stian.vestli/ra0244-01.git
Commit: 4bc8362e006d777cbeacdd33bd9c7669a7345e39
Man kan kjøre skjema rett frem for å reprodusere dette.

Viktig å ikke velge noen konflikter i multiple selecten, da denne vil filtrere repgruppene og en bug i dette vil fjerne legge til ny i repgruppene.

Additional Information

No response

[StianVestli]

org/ssb

[bjosttveit]

Confusing explanation incoming:

This turns out to be a bit of a complex issue, the reason for the repeating group closing appears to be that the input-field calls save on blur which causes the backend app to write data to the first repeating group and this triggers initRepeatingGroups. Now since the element in the second repeating group is not saved yet, it will set its editIndex to -1 because the current edit-index is greater than the length of the array. This functionality is necessary to make sure that an element that no longer exists is not open? If you first fill out some data in the new element in the second repeating group (like Antall), this will cause the new row to be saved and the row will not be closed when typing in the panel. However, the backend will still cause the first repeating group to save the new row (from the panel), and since the panel is set to use the repeatingGroupIndex of the first repeating group + 1, it will see this update and immediately create a new row for the first group again. Which results in the text-field (Arbeidskonflikt in the panel) getting cleared and a new element has been added to the first repeating group without getting the opportunity to fill in the second field inside the panel. 😪

The root cause has many different parts (complex redux business) and does not appear to be an easy fix, This issue once again comes to mind, also this. I agree that the data should not be saved until the save button is clicked, this would pretty much solve this issue, the problem is that the saving logic is handled by the component itself, and I think dealing with the technical debt is the best way to deal with this issue instead of complicating the existing code even more.

Maybe I missed something, maybe @olemartinorg has a simple fix up his sleeve.

[olemartinorg]

Woah - I'm barely able to follow this explanation through the twists and turns. The way I understand it, an easier fix for this might arrive in #555, as it could lead to a new row being created as soon as you press the button for it. I think we should postpone fixing this issue until we have the structures in place for it - it looks like a very complex edge-case.

[bjosttveit]

Correct, if the row is created when the add button is pressed, it would not close the row as the issue describes. The other issue where it instantly adds the new element to the first repeating group (and subsequently clears the input in the panel) would persist though.

[olemartinorg]

#555 is was implemented with v4. I suspect this issue is no longer present in v4. As all of the mentioned code paths that were causing this to fail are no longer present, and the 'which row is open' state has been simplified, I'm taking a chance and closing this issue as done.