Avklaring: Hvilke(n) ressurstype skal benyttes/støttes for Correspondence

[RagnarFatland-Avanade]

Lager en avklaringssak som samler noe inkonsistens jeg ser i forhold til Ressurstyper og Correspondence.

For min egen del bør spørsmålet til Migrering avklares, men resten har konsekvenser for resten av løsningen.

Flere ressurstyper i Ressursregisteret

Det finnes flere ressurstyper i Ressursregisteret.

• GenericAccessResources / Genrisk tilgangsressurs
• SystemResource / Systemressurs
• MaskinportenSchmea / Maskinporten Skjema
• BrokerService / Formidlingstjeneste
• CorrespondenceService / meldingstjeneste

Formålet med ressurstyper er å kunne legge til rette for enkel klassifisering/sortering, samt å tilrettelegge for spesialbehov.

For tilgangsstyring og Autorisasjon er det ingen forskjell på de fleste ressurstypene.
Det er bare MaskinportenSchema de har forskjellig håndterering/api/gui for i Tilgangsstyring.

Ingen restriksjon i Correspondence

Det ser ikke ut til å være en begrensing per nå i koden i Altinn-Correspondence som sjekker på ResourceType
Det er heller ikke angitt i Melding-dokumentasjonen på docs om hvilken ressurstype som skal benyttes.
Så i praksis er det mulig å benytte hvilken som helst??

Hittil har muligens Genriske tilgangsressurser blitt brukt til testing?

ResourceType=CorrespondenceService ??

ResourceType CorrespondenceService ble lagt til 21.05.2024 av @oskogstad som er en Dialogporten-utvikler.
Altinn/altinn-resource-registry#408
Altinn/altinn-studio#12822

Betyr dette at Dialogporten har et aktivt forhold til ResourceType?? Bør avklares.

Utfra navngivning så hadde det kanskje vært logisk å kreve at denne ressurstypen blir brukt til Altinn Correspondence?
Men mulig det gir en unødvendig restriksjon?
I så fall burde den kanskje vært sanert og man burde gå for å kun bruke Generisk Tilgangsressurser??

Denne Ressurstypen er heller ikke synlig på ressurs admin sidene, se under

Avvik i Ressursregister-kode / dokumentasjon

For å bidra til forvirringen er det avvik mellom koden: i ressursregisteret: https://github.com/Altinn/altinn-resource-registry/blame/main/src/Altinn.ResourceRegistry.Core/Enums/ResourceType.cs

Og i Ressurs admin sidene i Altinn Studio, har betydelig færre typer tilgjengelig.

Tatt fra https://altinn.studio/resourceadm/ttd/ttd-resources
Dokumentasjonen her er utdatert: https://docs.altinn.studio/authorization/what-do-you-get/resourceregistry/

Migrering fra Altinn 2

Siden migrering av Meldinger fra Altinn 2 kommer til å medføre at vi oppretter nye Ressurser/Meldingstjenester i Altinn 3 så trenger vi å få dette avklart slik at vi ikke migrerer for feil type.

Inntil videre vil Migreringsløpet benytte GenericAccessResources / Genrisk tilgangsressurs, med mindre vi får annen beskjed.

[elsand]

Dialogporten har et aktivt forhold til correspondence i den forstand at det kreves et eget scope for å opprette/endre/slette dialoger som refererer en ressurs med resourcetype=correspondence. Dette scopet er det kun Digdir (les: dere) som har fått.

Dette lar en hindre at tjenesteeiere kan tukle med dialoger som er opprettet av correspondence gjennom dialogporten-APIet, og lar correspondence har full og eksklusiv kontroll på disse.

Om correspondence velger å opprette dialoger som refererer en genericresource, blir dere ikke hindret i det, men da vil også den aktuelle tjenesteeieren også endre/slette denne i etterkant. Dette må isåfall hensyntas av dere mht oppdatering av dialogen (ifm lest-status etc).

[leogasnier]

Enig - vi bør av flere årsaker legge opp til bruk at "corr" som ressurstype - også av telle og loggehensyn muligvis? Vi har jo behov for endel data fra autorisasjon på dette.

Ville pekt brukere i retning ønsket ressurs, via docs, og ved å få det inn i studio-oppsettet (bilde i saken) men kanskje heller ikke behov for å fysisk sperre for andre typer, før "feil bruk" ev. utgjør et problem?

[Andreass2]

Ved å endre til Correspondence vil følgende skje:

• RRR må endre sitt gui til å støtte den nye typen
• Vi vil ikke lengre støtte apps, som vil gjøre en enkelt app om til en ressurs.
• Endringer på Dialogporten adapter(bytte scope).

I forhold til logging og telling, så er ikke dette noe problem med en generisk ressurstype. Vi ser ingen store fordeler med å bruke en egen ressurstype, da det kun vil gjøre det vanskeligere å kommunisere med apps.

Ref

Dialogporten har et aktivt forhold til correspondence i den forstand at det kreves et eget scope for å opprette/endre/slette dialoger som refererer en ressurs med resourcetype=correspondence. Dette scopet er det kun Digdir (les: dere) som har fått.

Dette lar en hindre at tjenesteeiere kan tukle med dialoger som er opprettet av correspondence gjennom dialogporten-APIet, og lar correspondence har full og eksklusiv kontroll på disse.

Om correspondence velger å opprette dialoger som refererer en genericresource, blir dere ikke hindret i det, men da vil også den aktuelle tjenesteeieren også endre/slette denne i etterkant. Dette må isåfall hensyntas av dere mht oppdatering av dialogen (ifm lest-status etc).

@elsand . Er dette ett problem? Det betyr vell i grunn at TE eier dialogen i dialogporten og har rettigheter til å gjøre endringer der?

[elsand]

Er dette ett problem? Det betyr vell i grunn at TE eier dialogen i dialogporten og har rettigheter til å gjøre endringer der?

Ikke nødvendigvis et problem, men dere må ihvertfall teknisk ta høyde for at ting kan ha endret seg (eller forsvunnet) når dere ønsker å foreta en oppdatering (som vi har mekanismer for, f.eks. gjennom PATCH eller bruk av etag/if-match).

Mer på et strategisk nivå er det vel spørsmål hvorvidt man ønsker at correspondence-tjenester skal representere noe annet enn "klassisk" digital post; jeg vil anta at det f.eks. finnes forventninger knyttet til at den type meldinger skal være uforanderlige og representere en "gjenpart" som brukeren eier, og ikke kunne endres/slettes willy-nilly av tjenesteeieren. Dette er noe som må vurderes opp mot diskusjonen med sluttbrukers arkiv.

Når det er sagt, er det vel tenkt at det på sikt skal bli mulig å bruke correspondence for å oppdatere en eksisterende dialog med en ny forsendelse (transmission); som f.eks. da kan være en dialog som i utgangspunktet er opprettet ifm en skjematjeneste i en app, og som tjenesteeieren (eller noen andre autoriserte parter) kan utvide med f.eks. vedtak eller andre dokumenter sendt gjennom correspondence.