Support multiple datamodels in the same task

[bjosttveit]

Description

Adds support for multiple data models in the same process task.

Configuration

This should be fully backwards compatible, and previously there was only one data model for a task as defined in layout-sets.json; I will refer to this model as the "default" data model, as this will always get loaded into the form, and will be used when refering to form data fields without explicitly specifying which data model to use. No changes to layout-sets.json are necessary to use multiple data models. In fact, having the "default" data model defined there is still requried due to some implementation specific reasons. This may not be required in the near future, but that depends on if we can do it without introducing breaking changes for existing apps.

To refer to other data models than the "default" one you need to specify which one explicitly in the layout files:

Data model bindings:

"dataModelBindings": {
  "simpleBinding": {
    "dataType": "data_model_name",
    "field": "path.to.property"
  }
}

Expressions:

["dataModel", "path.to.property", "data_model_name"]

Text resources works the same way as before, you could already refer to any data model there, the only difference now is that if you have multiple models that are editable, text resources refering to these models will now update as the data changes.

The app will automatically load any data models that are referenced in the layout files.
Note: dataModel-expressions are also checked for references. However, since we cannot actually run expressions before fetching data models, we can only detect data types that are referenced with a raw string. I.e. if you use an expression to set the dataType parameter in the dataModel expression, we cannot determine what data model to fetch and will log a warning.

Deprecated properties

Some existing component properties were not possible to extend to support multiple datamodels due to the way they were structured. Some of these properties now have replacements that should be just as good and also supports multiple data models. In these cases the old properties are now marked as deprecated, meaning that they will still work exactly like before, but we intend to remove them in a future major release. The properties now marked as deprecated are the following:

• mapping-property for options-based components:
  • RadioButtons
  • Likert
  • FileUploadWithTag
  • Checkboxes
  • MultipleSelect
  • Dropdown
• mapping-property for List component
• bindingToShowInSummary-property for List component

The mapping-property can be replaced with the queryParameters-property for all of the above, which has now been extended to support expressions so that you can reference the data model there instead. And since the dataModel and component expressions support multiple data models, queryParameters does too.

The bindingToShowInSummary-property for List can be replaced with the summaryBinding-property. The difference here is that instead of specifying the datamodel path, you specify one of the binding names from dataModelBindings. You could not specify a data model path that was not in the List component's dataModelBindings in bindingToShowInSummary anyway, so no functionality is lost.

Features that currently do not support multiple data models

• mapping-property for the PaymentDetails only works with the "default" data model, and is not deprecated because there is currently no replacement that maintains the desired functionality that also supports multiple data models. Handle updating PaymentDetails components orderlines without using deprecated "Mapping" #2102
• mapping-property for the InstantiationButton component. Create a feature request if you need support for multiple data models for instantiation with prefill.
• Backend features: RemoveHiddenData, RequiredValidation, and ExpressionValidation. Layout & Expression changes due to supporting multiple data models app-lib-dotnet#600

Other

Also fixes #2091, as any data model that is locked (already submitted in a previous task) will be designated readOnly. This entails that these models will not be validated, and writing to them will not work and will log an error to dev tools.

Related Issue(s)

• closes Support multiple data models in the same process task #1484
• closes Frontend validation should not validate dataModel in signing task #2091

Verification/QA

• Manual functionality testing
  • I have tested these changes manually
  • Creator of the original issue (or service owner) has been contacted for manual testing (or will be contacted when released in alpha)
  • No testing done/necessary
• Automated tests
  • Unit test(s) have been added/updated
  • Cypress E2E test(s) have been added/updated
  • No automatic tests are needed here (no functional changes/additions)
  • I want someone to help me make some tests
• UU/WCAG (follow these guidelines until we have our own)
  • I have tested with a screen reader/keyboard navigation/automated wcag validator
  • No testing done/necessary (no DOM/visual changes)
  • I want someone to help me perform accessibility testing
• User documentation @ altinn-studio-docs
  • Has been added/updated
  • No functionality has been changed/added, so no documentation is needed
  • I will do that later/have created an issue
• Support in Altinn Studio
  • Issue(s) created for support in Studio
  • This change/feature does not require any changes to Altinn Studio
• Sprint board
  • The original issue (or this PR itself) has been added to the Team Apps project and to the current sprint board
  • I don't have permissions to do that, please help me out
• Labels
  • I have added a kind/* label to this PR for proper release notes grouping
  • I don't have permissions to add labels, please help me out

[olemartinorg]

🫶

There's a few TODOs left in the code, but I'm thinking these can be left in there for now, and cleaned up at some point later.

[sonarcloud]

Quality Gate passed

Issues
19 New issues
0 Accepted issues

Measures
0 Security Hotspots
78.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarCloud