Validation trigger on group should re-validate on delete + new row

[olemartinorg]

Description

Adding "triggers": ["validation"] on a repeating group component does not have very well-defined behaviour. It should be possible to add this trigger, and have server-side validations re-run on the group data. In the related Slack discussion, an app was set up to validate that a group had at least 1 row (using server-side validations, but this should be supported by the JsonSchema validation as well).

Triggers on a repeating group should run when:

• Deleting a row (or rather, after a row has been deleted - as it might fail to delete)
• Adding a new row (in order to run server-side validations here, we'd have to fill out some empty data into the row components and pass that to the server)

The validations on the group should not run when saving data inside a component, as that should only trigger validation if that trigger is set on the component itself.

Related issue(s)

• Repeating groups: Validation trigger for single row #468
• Adding a "validation" trigger on a group component ignores "component"-specific validaitons #269
• Discussion on Slack: https://altinn.slack.com/archives/C03DX42K6AY/p1666075681994599
• Other related dicussion: https://altinn.slack.com/archives/C02EVE4RU82/p1665565549630379 (consider if the need to trigger something on adding a new row is a different need, and should be implemented differently)
• Yet more discussion: https://altinn.slack.com/archives/C03DX42K6AY/p1675249074411239 (a use-case where it would be useful to know when a row is opened for editing, a new row is added, and potentially a trigger for deleting a row).
• NB! Will potentially be solved by Experiment: Storing the data model in a Context #1175

[RonnyB71]

Potential breaking change and should maybe be pushed to a new major version.

[olemartinorg]

• Considerations for v4 #339

[FinnurO]

There are other issues related to validation which could be useful to look at in order to get a complete view of the validation area.

[olemartinorg]

I have an update on this, and a suggestion for a less breaking solution. It was originally thought we needed to introduce a breaking change for this to work, because adding a new row to a repeating group should (naturally) set all the fields in the group to empty values (and pass this as a single save operation to the backend). However, we can continue on with the current functionality and add this behaviour as an optional feature (in the form of a trigger) without breaking backwards compatibility.

My new suggestion for a solution here is to add multiple triggers for operations the user is performing. I've read through the relevant discussions again, making sure this solution should cover the use-cases.

So, right now this is our possibilities:

{
  "type": "Group",
  "triggers": ["validation", "validateRow"]
}

For most other form components, it's implicitly meant that these triggers are triggered when saving, and this is also the case for groups (but only repeating groups). That is, we run this trigger when the user clicks 'save and close' for a row. Triggering validation seems to trigger validation for all rows of the repeating group, while the newer validateRow aims to do the more sensible thing and only run validation for that row.

But for repeating groups, there are more actions than just saving. You can:

1. Add new rows (opening them for editing in the process)
2. Open existing rows for editing
3. Delete rows (while editing, and while not editing), potentially after confirming it using "alertOnDelete": true
4. Close a row for editing (aka 'save and close')

We have functionality to trigger validation on the entire row before action 4 completes, and action 3 will implicitly trigger a call to the backend (because we need to save the changes to the data model). As for the rest, we do not have any triggers for these.

And we find there are two different results for these triggers; either:

a. Saving
b. Validating

An obvious candidate here is to support a trigger for saving a new row as soon as it is added (1->a). That would mean a new row would be created (representing a new object inside the array in the data model) with empty values, passed to the backend where new data could be added to the row via ProcessDataWrite. We should probably also pass the group ID and indexes (for nested groups) as metadata when triggering this. Triggering validation when adding a new row (1->b) is likely never a relevant usecase.

Another candidate is triggering saving when opening or closing a row (2->a and 4->a), but since no data actually changes, it might be breaking a few expectations. However, the backend might want to make changes to the data model when this happens, such as adding a "rowDataLocked": true when closing the row for editing, causing the save operation to actually mutate the data model again. How this interacts with existing triggering of validation (4->b) is unclear. Do we trigger saving regardless of validation outcome?

So in essence, my suggestion here would be to expand the "triggers" property for repeating groups to support:

{
  "type": "Group",
  "triggers": {
    "addAndOpen": ["save"],
    "openExisting": ["save", "validateRow"],
    "delete": ["validateRow"], // Happens before actually deleting, and the 'save' will always trigger
    "close": ["save", "validateRow", "validation"] // This is the existing functionality, apart from the new 'save'
  }
}

All of which would be backwards-compatible.

[mikaelrss]

I seem to be able to enter a state where the validation call is not being triggered when a row is added or deleted.

Steps to reproduce:

1. Go to the group page of frontend-tests.
2. Select the first prefill option og page 1.
3. Navigate to the next page.
4. Open the repeating group.
5. Add an item to the repeating group.
6. A validate call should be run.
7. Delete this new row.
8. See that a validation call is not run.
9. Subsequent add or delete actions do not trigger validate.

ezgif-4-3a88aa90dd.mp4

[mikaelrss]

Tested this with v4.0.0-rc1 and this seems to be fixed 🥳