Support for binding an attachment control to a repeating element in the data model

[RogerKjaernsrod]

In the App MT-3 (Økokrim) Altinn/app-migration#5 there is a need for the possibility of binding attachments to a repeating element in the data model. Økokrim would like to have the user add extra information about each attachment. Like this:

What needs to be solved?

A change of the attachment control to support binding it to an element in a repeating group in the datamodel would solve this.

How do you want it solved?

Adding the option of binding an Attachment control to an element in the datamodel. Should support both repeating and single instance elements.

Additional context

Currently the App crashes if you add an attachment control to a repeating group in the designer.
It does not crash designtime. It crashes when you open the App an click the "Add new" link to add a new row to the repeating group.

Analyse

Where to connect data to an element in a group

Reference to the data element from group element

In this scenario, the data model for the form would need a list of strings connected to the group element.
In this way, each element in the group will have a reference to the connected data element.

Reference from dataelement to group element

In this scenario, each element would need a reference to the correct group and element

The hypothesis is that option 1 is best.

Are there a need for multiple types of documents related

If there is a need for more than one type of attachment for one group?

Currently, if there is a need for that that would require multiple file uploads per row in the group

[acn-dgopa]

We also require that the attachment component can be added in nested groups @TheTechArch @FinnurO

[FinnurO]

Relatert til Altinn/altinn-studio#6479?

[SandGrainOne]

Relatert til Altinn/altinn-studio#6479?

@FinnurO Det er teknisk mulig å bruke tags til å lagre informasjon om relatert data element, men jeg har forstått det slik at vi ønsker at kobling til data skal være litt mer eksplisit. Tags egner seg ikke like godt.

[RogerKjaernsrod]

Relatert til Altinn/altinn-studio#6479?

#259 (denne) er egentlig ikke relatert til Altinn/altinn-studio#6479.
Denne gjelder støtte for å ha vedlegg inne i en repeterende gruppe, mens Altinn/altinn-studio#6479 gjelder det å tagge/markere et spesifikt vedlegg slik at man vet hva vedlegget gjelder.

[FinnurO]

@SandGrainOne @altinnadmin @lorang92 @RonnyB71 Ref det vi diskuterte. Kan dere se på denne og se om det er noen synergier med Altinn/altinn-studio#6479 ? Behovet er jo: "Økokrim would like to have the user add extra information about each attachment. ", så det er attributter på et vedlegg, selvom vedlegget inngår i en repeterende gruppe.

[RogerKjaernsrod]

@SandGrainOne @altinnadmin @lorang92 @RonnyB71 Ref det vi diskuterte. Kan dere se på denne og se om det er noen synergier med Altinn/altinn-studio#6479 ? Behovet er jo: "Økokrim would like to have the user add extra information about each attachment. ", så det er attributter på et vedlegg, selvom vedlegget inngår i en repeterende gruppe.

Denne saken er egentlig ikke det samme som Altinn/altinn-studio#6479, for denne saken gjelder det å kunne ha en vedleggskomponent "inne i" en repeterende gruppe slik at man kan ha andre felter (elementer) i datamodellen "rundt" vedlegget som skal brukes til angi informasjon om hva det aktuelle vedlegget gjelder.
Så for å kunne lage Appen slik Økokrim har sett for seg, så trengs det en endring slik at man kan "koble" en vedleggskomponent til et felt i datamodellen. Og i tillegg at kontrollen kan kobles til et felt i en repeterende gruppe i datamodellen.

[TheTechArch]

@RogerKjaernsrod er det behov for å kunne laste opp flere typer vedlegg til et element i gruppen? Eller er det bare 1-1?
Er det også slik at det bare er 1 dataelemement? Aldri behov for en liste av element pr gruppeelement? (f.eks laste opp flere transaksjoner tilknyttet en sak)

[RogerKjaernsrod]

@TheTechArch Behovet er at man kan ha en vedleggskomponent inne i en repeterende gruppe og at man kan koble vedlegget til denne gruppen. Enten ved at man kobler komponenten til et element i datamodellen eller at man på et annet vis kan identifisere hvilke vedlegg som hører til hver repetisjon i gruppen.
Og i Økokrim sitt tilfelle så er det snakk om å ha vedleggskomponenten i en repeterende gruppe som ligger i en ytre repeterende gruppe.
Så det er 2 ting man trenger her. Det ene er støtte for å ha vedleggskomponenten (visuelt) inne i en repeterende gruppe i appen. Og at implementasjonen ikke begrenses til å bare kunne ha komponenten i en "ytre" repeterende gruppe, men at den kan ligge i en repeterende gruppe i en repeterende gruppe, osv.
Og det andre er å kunne identifisere hvilket vedlegg som hører til hver repetisjon i gruppen komponenten ligger i. Og evt hvilken repetisjon i repetisjon hvis komponenten ligger i en rep gruppe i rep gruppe.

[SandGrainOne]

@RogerKjaernsrod Vi diskuterte litt i går i hvilken rettning det skulle lages en kobling mellom data og vedlegg.

1. Vedleggets dataelementid lagres i skjema. Dette vil kreve at datamodellen/skjemamodellen utvides med et felt til dette formålet. Vi er litt usikre på i hvor stor grad apputviklere vil kunne gjøre slike tilpassninger i skjemamodellen.
2. Vedlegget (DataElement modellen) blir utvidet til å ha en slags peker til "noe" i datamodellen. Dette vil potensielt også kunne kreve datamodell endringer. Noe som kan unikt identifisere de relaterte data. Vi er litt bekymret for at en array index i en repeterende gruppe kan bli for tynt å skape en litt for svak binding, men det er mulig å løse.

Et tilleggspørsmål er om dere ser for dere at vedlegg automatisk slettes når dataene det er koblet til blir slettet?

Har dere selv noen tanker om dette?

[RogerKjaernsrod]

@SandGrainOne

1. Det bør være valgfritt om man vil koble vedlegg til et element i datamodellen. Da vil de som ønsker det kunne legge inn et element i appens datamodell som kan brukes til å binde vedleggskomponenten til.
2. Litt usikker på hva som menes her? Det må vel uansett ligge "noe" i datamodellen for å kunne koble et spesifikt vedlegg til en rad i en repeterende gruppe?

Ja, det er vel greit at et vedlegg som ligger i en rad i repeterende gruppe slettes samtidig som raden slettes.

[TheTechArch]

@RogerKjaernsrod dette noe er det feltet som legges til i datamodellen.

[RogerKjaernsrod]

@TheTechArch Ja, det "noe" vil være elementet i datamodellen som kontrollen bindes til.
Jeg tenkte litt mer på dette og det er vel egentlig ikke noe poeng å ha det valgfritt å koble kontrollen til et element i datamodellen. I hvert fall ikke hvis den skal ligge i en repeterende gruppe. Da kan det vel være et krav til utvikler at man kobler den til et element i datamodellen?

[TheTechArch]

@RogerKjaernsrod ja jeg tenker det nesten må være et krav hvis man faktisk ønsker denne knytningen mellom gruppen og filen.

Men tenker du det holder med alltid kun et element, eller bør det være en liste.

[RogerKjaernsrod]

@TheTechArch Jeg tenker at det holder med et element, hvis det er snakk om ett vedlegg per repetisjon?.

[olemartinorg]

Pull request opprettet her:

• Support for attachments in repeating groups #246

Utvikling i frontend rundt denne saken er godt i gang, og er foreløpig i branchen feature/7659-attachment-in-repeating-group. Til nå har jeg laget det slik at UUID-en til et vedlegg er det som lagres ned i datamodellen, men om det ønskes noe annet ønskes kan dette endres på. @acn-sbuad foreslo filnavnet heller, men det er ikke nødvendigvis unikt.

Jeg har også laget en app jeg tester dette i, som skal ha alle mulige kombinasjoner av vedleggskomponenten.

Denne saken omfatter mye, så jeg skal prøve å vedlikeholde en gjøremålsliste her:

• Lage støtte for lister med strenger i datamodellen (type="xsd:string" maxOccurs="5" gav feil i generert .cs-fil).
  • Studio: Support for arrays containing primitive types  altinn-studio#8537
• [x] Undersøke hvorfor appen kræsjer, samt fikse det Jeg fikk aldri problemer med kræsjing, så jeg går ut ifra at problemet er løst (og urelatert).
• Lage støtte for å knytte vedlegg til komponenter som ikke er på rot-nivå (attachmentType/dataType ikke lengre er lik component.id når vedlegg lastes opp på komponenter i repeterende gruppe)
• Utsette kjøring av mapAttachments til etter skjemadata er hentet fra instansen, samt bruke data fra datamodellen til å knytte vedlegg til riktig rad i en repeterende gruppe.
• Sørge for at vedleggsreferansen blir fjernet igjen fra datamodellen når vedlegg slettes, samt at senere vedlegg blir flyttet oppover.
• Sletting av en rad i en repeterende gruppe skal føre til sletting av alle tilknyttede vedlegg, samt vedleggsreferanser i datamodellen.
• Løs opp i problemer med visning av rad i repeterende gruppe når slettingen ikke lengre er umiddelbar
  • Hindre dobbel-sletting/deaktivere sletteknapp
  • Indikere for brukeren at vi venter på å slette vedlegg
  • Hindre lukking av raden og sletting av flere data dersom sletting av et eller flere vedlegg feiler
• Sørge for at saga-kappløpet som venter på fullføring av vedlegg-sletting ikke fullfører for tidlig om helt urelaterte vedlegg blir fullført slettet i mellomtiden
• Forsikre at det også fungerer med vedleggsreferanser som ikke er lister (maxOccurs="1", som blir til string istedenfor string[])
• Verifisere at mapAttachments og knytningen mellom vedleggskomponent og formData i repeterende grupper fungerer med flere sider/layouts.
• Verifisere at mapAttachments kjører riktig ved instansiering via InstantiationButtonComponent (eller bare fjern det kallet om det ikke er nødvendig)
• Verifisere at FileUploadWithTag-komponenten fortsatt fungerer, og henger med på endringene
• Verifisere at valideringsmeldinger (for minimum antall vedlegg og påkrevde felt) fungerer
• Verifisere at ingen apper i produksjon har IDer som nå vil skape problemer, ettersom upload-1 ikke ble tolket tidligere, men nå blir tolket som upload i andre rad i en repeterende gruppe.

  apps-launched $ find . -type f -name '*.json' | grep 'App/ui' | xargs -L 1 jq -r '.data.layout | values[] | "\(.type) \(.id)"' | grep -i -P '^FileUpload.*?\-[0-9]+$'

• Erstatte visning av uuid på oppsummeringsside med filnavn
• Erstatte visning av uuid i tabell over innhold i repeterende gruppe (f.eks. "vedlegg1.pdf, bilde.jpg og 3 andre vedlegg" istedenfor)
• Verifisere funksjonalitet i generert PDF (Her vises UUID - det vil noteres i dokumentasjon at det anbefales å fjerne feltet fra pdf-generering)
• Lage unit-tester for ny/endret funksjonalitet
• Lage cypress-tester for opplasting av vedlegg, sletting av vedlegg og vedleggsreferanser
• Skrive utviklerdokumentasjon
  • Adding docs for attachments in repeating groups altinn-studio-docs#550
• [ ] Finne en utviklervennlig måte å informere om at datamodell-knytning kreves for vedlegg i repeterende gruppe (kaste en exception?) Denne utsettes til fordel for tydelig dokumentasjon og påfølgende innhøsting av erfaringer.
• [ ] Utvide Studio med mulighet til å legge til datamodell-knytning på vedlegg (ikke bare i repeterende gruppe), samt automatisk velge simpleBinding/list av hvor mange vedlegg man har mulighet for å laste opp
  • Skilles ut til eget issue:
  • Studio: Support for data bindings for for attachment components altinn-studio#8664
• Under utvikling ble det oppdaget at DatePicker-komponenten ikke har støtte for validering av minDate/maxDate inne i en repeterende gruppe. Dette bør enten ryddes opp i eller lages en issue på. (DatePicker validations for minDate/maxDate not working in repeating groups #185)

Viktige punkter å få med under review og testing:

• Automatisk sletting av vedlegg ved sletting av rad i gruppe gjelder også ved nøstede repeterende grupper
• Disse endringene gjelder også FileUploadWithTag
• Muligheten for å knytte vedleggskomponenten til datamodellen gjelder også utenfor repeterende grupper

[RogerKjaernsrod]

Ref punktet over: "Utvide Studio med mulighet til å legge til datamodell-knytning på vedlegg (bare når i repeterende gruppe?)"
Jeg tenker at det ikke bør begrenses til kun repeterende grupper.
Det kan være tilfeller hvor man ønsker å knytte et vedlegg til et spesifikt felt i modellen/appen også når det ikke er repeterende.
Det kan være at man feks skal legge ved en attest for innsender og daglig leder i firmaet. Disse vil ikke være repeterende, men det kan fremdeles være ønskelig å vite hvilket vedlegg som hører til hvilken person.

[olemartinorg]

Helt enig, @RogerKjaernsrod! Jeg utvider gjøremålslista.

[olemartinorg]

This should now be solved, and I'm assuming the testing on your end was successful, @RogerKjaernsrod. If not, let me know!