Validate and warn about invalid application configuration

[olemartinorg]

Description

This need has been thought of and discussed a lot before, and while we would like to produce warnings/errors for invalid configuration in Altinn Studio, rapid feedback on changes is needed, so having these warnings in app-frontend-react as well might lead to a better developer experience for those working on their app locally. The code should preferably be written in a way that makes it possible to extract the code to also show warnings in Studio.

Suggested validations

• Groups/repeating groups
  • [x] Group/component order. Groups should be defined first(?), and all children later in the layout. We should show a warning if a child is defined before the group. No longer an issue in app-frontend
  • [ ] All children in the group should exist. Show a warning if a child component ID does not exist (or exists in another page/layout). Should of course also work when groups have a multiPage configuration.
  • [ ] Check that children are not re-used across multiple groups.
  • [x] Only allow two levels (regular repeating groups and nested repeating groups) We theoretically support unlimited depth of repeating groups, although this will probably not look great in the UI.
• Component IDs
  • [ ] Warn about duplicate component IDs, even when IDs are duplicated across pages/layouts (hidden components will not differentiate on the page id, so duplicate component IDs across pages will have unintended consequences)
  • [ ] 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>)
• Data model bindings (moved to #1463)
  • [ ] Missing dataModelBindings for components where a binding is expected
  • [ ] dataModelBindings pointing to non-existing locations in the data model (use Levenshtein to find the correct one?)
  • [ ] dataModelBindings pointing to invalid types in the data model
  • [ ] I.e. Input supports strings and numbers (and with numeric data types, number formatting should be set)
  • [ ] Booleans are not supported/recommended (#205)
  • [ ] Repeating groups should have their group binding pointing to an array-type in the data model
  • [ ] Non-repeating groups should have all its children bound to properties of the same object in the data model(?)
  • [ ] Components inside groups must have their bindings contained within an object inside the array-type of the group binding
• Other component configuration
  • [ ] Missing textResourceBindings where a binding is expected
  • [ ] Properties for certain components that should be required and valid
  • [ ] Checkbox group, radio, select etc needs options in some way
  • [ ] Verify summary component reference
  • [ ] Check that groups with panel and groupReference points to an existing repeating group
  • [ ] FileUpload* components, when used inside repeating groups, should have a list data model binding
  • [x] textResourceBindings using keys that does not exist. As the keys are optional, we could potentially use a Levenshtein algorithm to warn when the binding is almost equal to a known text resource ('did you mean ___?'). Should be covered by JsonSchema validation
  • [ ] All the warnings for dataModelBindings should apply to variables in text resources
  • [ ] All the warnings for dataModelBindings should apply to dataModel lookups in expressions
  • [ ] Error if maxFileSizeInMB greater than maxSize set on the connected DataType in applicationmetadata.json, warning if smaller
  • [ ] For components utilizing options, you should only define source OR options OR optionsId (and secure should only be set if using optionsId). If you set multiple of these, you depend on the order of the code that checks for these properties (which may be different in frontend/backend).
• Layout generic
  • [ ] Verify that all layout files validate according to the current layout JsonSchema Moved to #1512
  • [ ] Warn if using older layout structure, not layout-sets
• XACML Policy
  • [ ] Verify correct resources defined (app, org, task). Does it match metadata & BPMN
  • [ ] Is the roles correct
  • [ ] Does all rules define resource, action, and subject
  • BPMN
  • [ ] Flow between all tasks
  • [ ] End and start
  • [ ] Correct task types
• Other
  • [ ] Include all the warnings/errors from expression validation (this is already implemented in app-frontend-react)
  • [ ] Complain with an error if the (current) process Task (when using a data process type) does not have a data model
  • [ ] Check the version of nuget packages used, and warn if they're older than what we support
  • [ ] Check the frontend version used, and warn if it's older than what we support
  • [ ] Paths in presentation fields, and their data types:
  • https://altinndevops.slack.com/archives/C045EB3JA9X/p1706020139996529

Relevant issue(s)

• https://github.com/Altinn/app-lib-dotnet/issues/134
• https://github.com/Altinn/app-frontend-react/issues/743
• https://github.com/Altinn/altinn-studio/issues/1841
• https://github.com/Altinn/altinn-studio/issues/6503

  
  ### Tasks

• [ ] https://github.com/Altinn/app-frontend-react/issues/1463
• [ ] https://github.com/Altinn/app-frontend-react/issues/1512

[ivarne]

Jobber med dette i app-lib-dotnet https://github.com/Altinn/app-lib-dotnet/compare/feature/backend-dynamics...ivarne:app-lib-dotnet:app-validator

[olemartinorg]

@RonnyB71 @mijohansen Dette ble såvidt nevnt i møtet i går, så jeg tenkte å pinge dere her. Jeg har laget et forslag med ting jeg ønsker at vi validerer i en app, og at vi produserer en liste med potensielle feilmeldinger/advarsler om en gitt app.

Som nevnt over er det allerede påbegynt en implementasjon av dette i app-lib-dotnet, men jeg vil påstå at app-frontend-react er riktig repo å ha dette overordnede verktøyet i. Vi har såvidt jeg har skjønt flere ulike behov/stadier av app-utvikling hvor vi ønsker denne formen for validering:

• Man ønsker gjerne å få slike advarsler så fort som mulig når man utvikler lokalt - slik at man slipper å finne ut via prøving og feiling at f.eks. en duplikat komponent-ID førte til uventet oppførsel. Når man jobber lokalt jobber man med LocalTest, app-frontend og har hentet inn nuget-pakkene og startet appen.
• Disse advarslene ønskes også vist i Studio, før man kjører deploy av appen.

Jeg tenker det er viktig å ha kode som validerer layout lokal, det vil si i nærheten av hvor layout blir brukt. Hvis vi legger til en mulighet i layout via en ny feature i app-frontend er det mest naturlig at vi også skriver koden som validerer om denne blir brukt riktig her i dette repoet - og til enhver tid vil det jo være app-frontend som leder an i forventningen om hva som er "riktig" layout. Layout blir i langt mindre grad lest og brukt på backend, dermed tenker jeg det er unaturlig å legge valideringen av layout der. Samme med Studio - det verktøyet produserer layout, men konsumerer det ikke, så det hjelper lite å bygge valideringslogikk for layout et sted som ikke har god kjennskap til hvordan layout blir brukt.

Det er riktignok en god del konfigurasjon på backend også, og det er gjerne mest naturlig at nuget-pakkene selv sørger for validering for å sjekke om den konfigurasjonen er riktig i appen.

Mitt forslag:

• Validering lages som et kommandolinje-verktøy i app-frontend-react, hvor valideringen i utgangspunktet leser en App-mappe og bygger opp valideringsmeldinger som vises. I tillegg, om nuget-pakkene er nye nok, kalles en ekstra funksjon som kjører appen og ber den om nuget-pakkene sine valideringsmeldinger. Disse sendes til kommandolinjeverktøyet via et JSON-format - og alle meldingene flettes til slutt sammen til et sammenstilt format.
• Kommandolinjeverktøyet kan kjøres av Studio på en utsjekket kopi av master-branchen til appen før deploy, og JSON-resultatet kan vises pent i Studio.
• Frontend kan potensielt også produsere (noen) av meldingene ut fra f.eks. layout som den får under kjøring, slik at utvalgte meldinger kan vises i grensesnittet når en tjenesteutvikler jobber lokalt. Da kjøres altså ikke verktøyet mot en mappe, så det er litt mer begrenset hvilke valideringsregler som kan kjøres.
• Om Studio uansett skal hente inn app-frontend for Preview-modus, kan det kanskje kommuniseres slike valideringsmeldinger fra app-frontend til Studio underveis i utviklingen også.

[bjosttveit]

Dette punktet:

[ ] 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 -)

Er vel på sett og vis løst av #1512 siden det ligger vel i regexen for id? Den gir i alle fall feil om at component-ider som summary-1 ikke matcher regexen. Nå er ikke den feilmeldingen spesielt brukervennlig da men.

[ivarne]

Regex regelen treffer mye mer en den bør. Kombinasjonen av masse falske positiver og en melding jeg knapt forstår noen måneder etter at jeg var med å feilsøke problemet gjør at jeg er uenig i at den er løst.

[bjosttveit]

Vi kan eventuelt velge å suppresse den warningen hvis vi legger inn en "custom" validering av komponent-ider

[ivarne]

Hvis du får en feilmelding som bare treffer skjema med kollisjon på repeterende grupper, kan jo bare regex fjerneres fra json schema

[olemartinorg]

Regexen er kanskje ikke optimal, men det har ikke kommet forslag om en som er mer optimal heller. Uansett - jeg synes det gir verdi å vise en feil om dette i vscode også, så jeg synes regexen skal bestå uavhengig av hva vi lager av verktøy i frontend.

Synes forsåvidt også vi kan "fiffe opp" akkurat den meldingen slik at den gir mer informasjon om hva man faktisk må gjøre for å fikse problemet, så det punktet kan godt ligge uløst her fortsatt.

[olemartinorg]

Ref denne diskusjonen:

• https://altinndevops.slack.com/archives/C045EB3JA9X/p1706020139996529

Jeg tenker vi kanskje burde bygge dette slik at det kan brukes som regler i eslint. Men i tillegg også et API som kan brukes av Studio og hentes inn som en egen pakke der, og da lokal støtte (gjerne via noe som eslint). Jeg ser for meg at vi kan eksportere en pakke fra app-frontend-react til npm, slik at vårt app-cli-verktøy også kan hente inn og kjøre eslint. Da kan vi også få automatisk verktøystøtte rett i editoren dersom man f.eks. bruker vscode - samt implementere automatiske fikser for problemer vi vet hvordan kan løses med kode - f.eks. å bytte ut $schema-stien i alle layout-filer og diverse med riktig sti på CDN.

eslint gir oss et mye kraftigere verktøy enn vi får med ren JsonSchema, og vi kan nok også laste inn andre filer (som applicationmetadata.json) for å gjøre mye dypere analyser av konfigurasjon enn det som da gjøres i dag.

Et neste alternativ er kanskje å lage en skikkelig "Altinn language server" som da også gir deg skikkelig god integrasjon i en editor, med forslag til refaktoreringer osv. Jeg begynte såvidt å se på det en gang i forbindelse med et stunt jeg tenkte å prøve meg på (i løpet av et litt kjedelig møte), men det var åpenbart ikke noe som stod på noen plan, så det ble ikke jobbet videre med den gang.