Support for shadow fields in app form

[nkylstad]

Description

We currently only support storing data in the data model. If a shadow field is required to f.ex. store some data needed for f.ex. dynamics in the form, this needs to be part of the data model and as such will also be submitted with the final data (unless app developer writes some custom code to scrub out this kind of data).

We should support the concept of shadow fields, that is, fields that can contain data, but are not connected to the data model in any way.

Additional Information

A first try at defining how we can support this.

• Shadow fields should be stored as flat key/value pairs.
  • Naming convention from frontend could be <page>.<componentId>, to make sure keys are unique.
• No model connection, so would have to be deserialized to f.ex. a dictionary with string values in order to be used in any server-side calculations.
  • App developer needs to know the keys that are used
• Frontend components - formData:
  • If no dataModelBindings are present for the component, use naming convention for shadow field to read/write data.
  • If dataModelBindings are present, these are used instead
• API - probably need new endpoint to save/fetch shadow field data.
  • For a POC, we could just add a new data type in applicationMetadata and use a naming convention, so that we can store/fetch the data using existing data endpoint.

The outlined solution supports rendering forms without any data model connection. It also supports a hybrid solution where some fields are connected to data model while others are true shadow fields.
One issue is that it could be difficult to validate the data submitted as shadow fields.

Alternative: Generate a data model from UI schema. This would enforce a contract of WHAT can be submitted/stored as a helper field, and allow for full deserialization and intellisense on server level. In this case we could have the same implementation frontend as suggested above.

Open questions

• Where do we store this type of data?
  • One set of shadow fields stored per instance? Per data element/task?
• Should the data be stored after the instance is submitted/archived?
• Store data as flat key/value pair list with no data model, or generate data model?

Tasks

• Decide on implementation
• POC

Acceptance Criterias

• Possible to render a form and store/fetch data without connecting fields to a data model.
• Possible to enter/store helper data that is not submitted with the rest of the form data
• Possible to use values in helper fields in server-side calculations/validations

[olemartinorg]

I'm moving this from altinn-studio to app-frontend-react. Let me know if you disagree with that, @nkylstad. I believe this should start with a PoC in the app frontend, along with the proper APIs in app-lib-dotnet.

Another way to think about this is 'the generic data model where form values are stored when they don't have a data model binding'. If we go ahead with #345, it might make things way easier. The way I envision that solution is that we keep all current values/state on components in the same location as the rest of the component state in redux (or any other shared state storage), instead of in the formData state. When time comes to save data, we can put some values in the provided data model, other values in this 'shadow' model.

Other open questions:

• What about repeating groups?
  • We want to get rid of state-keeping in the component id, where we currently add row indices like myComponent-0-1. Keeping this structure flat might make it harder for us to represent repeating groups.
  • If we allow for app developers to read/write this data and use it for dynamic expressions, how do we make sure state is kept in sync when rows are added/deleted?

Other terms for this concept:

• Hjelpefelt

[FinnurO]

Some references on how this works in Altinn 2: - https://altinn.github.io/docs/tul/vedlegg/a/#altinn-definerte-inputfelt and - https://altinn.github.io/docs/tul/vedlegg/a/#hjelpefelter-verdioverf%C3%B8ringer

[andersrodahl-brreg]

Brønnøysundregistrene ser nytten av å innføre "shadow fields" eller hjelpefelter og kan kommentere litt på hvilke konkrete behov for dette vi har sett i skjemaet brg/rrh-innrapportering:

• Ved instansiering av skjema hentes prefilldata fra brg. Prefilldata inneholder bla 2 felter metadata/tjeneste og metadata/tjenestehandling. Ved instansiering kopieres først disse feltene over til skjemaets datamodell/xsd. Deretter benyttes innebygd funksjonalitet i Altinn for å overføre disse feltene til key/value-felter på selve app-instansen.
  Se denne issuen som beskriver hvordan det fungerer: Add data from form to Instance as metadata altinn-studio#5864
  Når brg senere henter/mottar skjemaet (ved å kalle StorageAPI) kommer disse verdiene som en del av dataene på app-instansen, og brg kan bruke disse feks til å styre meldingene videre til riktig baksystem
  Det hadde vært en fordel om vi hadde sluppet å gå via datamodellen/xsd for å få overført feltene til app-instansen.
  Det beste hadde vært om man i InstantiationHandler kunne fått overført feltene fra prefilldataene over til app-instansen uten å måtte gå via datamodellen da dette er felter vi ikke trenger å få inn som en del av skjemaet.
  Behov oppsummert: Mulighet til å overføre felter til app-instansen uten at det må knyttes til datamodellen/xsd. Det er mulig dette kan gå via "shadow fields" i stedet.

• Skjemaet har funksjonalitet for å søke opp en person fra FREG ved at man angir fødselsnummer + de 4 første tegnene i etternavnet. For å understøtte denne funksjonaliteten har vi måttet ta inn følgende felter i datamodellen:
  soekEtternavn
  navnesoekFeilkode (liste)
  Disse 2 feltene ligger som en del av en repeterende liste (reellRettighetshaver).
  Dvs det kan være flere reelle rettighetshavere som blir registrert i skjemaet, og hver av disse vil da ha disse 2 feltene.
  Hvis feltene skal skilles ut som "shadow fields" må vi ha en måte å koble disse til riktig forekomst i lista over reelle rettighetshavere.
  Vi ønsker ikke å motta disse 2 feltene som en del av skjemadataene og ønsker at disse ikke skal være en del av datamodellen.
  Behov oppsummert: Støtte for "shadow fields" som kan knyttes til en bestemt forekomst i en repeterende liste, og som ikke blir en del av datamodellen for skjemaet

• Sporvalg / betingede valg
  I skjemaet har man valget om man skal registrere en norsk eller utenlandsk person som reell rettighetshaver.
  Dette valget gjør man ved å bruke radioknapper.
  For å få til dette måtte vi ha med et felt "erRegistrertIFolkeregisteret" i datamodellen.
  Behov oppsummert: Støtte for "shadow fields" som kan knyttes til en bestemt forekomst i en repeterende liste, og som ikke blir en del av datamodellen for skjemaet

• Status på prefilldata som hentes inn ved instansiering
  I skjemaet må vi ha kontroll på hvilke rettighetshavere som er hentet inn gjennom prefill ved instansiering og hvilke rettighetshavere som har blitt lagt til under utfylling.
  For å få til dette måtte vi ha med et felt "erPreutfylt" i datamodellen.
  Behov oppsummert: Støtte for "shadow fields" som kan knyttes til en bestemt forekomst i en repeterende liste, og som ikke blir en del av datamodellen for skjemaet

• Visning av data fra ekstern datakilde
  I skjemaet har vi i noen tilfeller behov for å hente ut og vise en liste over rolleinnehavere i en virksomhet.
  Disse dataene hentes fra Åpne data fra Enhetsregisteret.
  For å få til dette måtte vi ha med felter for roller som en del av datamodellen.
  Behov oppsummert: Støtte for å vise data i skjemaet som stammer fra en ekstern datakilde (feks et RestAPI), men disse dataene skal ikke være en del av datamodellen.

• Labels for visning
  I skjemaet har vi en liste som viser alle de reelle rettighetshaverne man har registrert.
  Kolonnen "Posisjon" inneholder en beskrivelse av hva som er registrert på rettighetshaveren. Innholdet i denne kolonnen er satt sammen / konkatinert basert på data fra andre felter.
  For å få til dette måtte vi ha med feltet "posisjonBeskrivelse" i datamodellen.
  Behov oppsummert: Støtte for "shadow fields" som kan knyttes til en bestemt forekomst i en repeterende liste, og som ikke blir en del av datamodellen for skjemaet

• Status for kommunikasjon med eksterne API'er
  I skjemaet har vi måttet ta inn følgende 2 felter:
  hentPreutfyllingFeilet
  hentRollerFeilet
  Disse feltene ble lagt til pga vi må ha kontroll på om kommunikasjon mot API for preutfylling og roller har feilet mtp om vi må trigge uthenting på nytt eller ikke på et senere tidspunkt.
  Behov oppsummert: Støtte for "shadow fields" som ikke blir en del av datamodellen for skjemaet

[olemartinorg]

Closing as done. Documentation here: https://docs.altinn.studio/nb/app/development/configuration/shadowfields/