altinn / altinn-correspondence Goto Github PK

Description

Epic har som mål å sørge å bidra til en sikker, smidig og effektiv overgangsprosess fra eksisterende til ny løsning.

Epic omfatter alle aktiviteter som er nødvendig for å forberede, gjennomføre og evaluere overgangsprosessen. Dette inkluderer utarbeidelse av dokumentasjon og veiledninger for å sikre at alle interessenter, fra utviklere til sluttbrukere, har den informasjonen de trenger for å forstå, bruke og støtte den nye løsningen effektivt.
Det er viktig å minimere risiko for driftsbrudd på tjenesten, derfor er også strategi for parallellkjøring en del av denne epic. Hvordan kan dagens løsning og ny løsning eksistere side om side i en begrenset periode?
I tillegg vil utviklingen av robuste migreringsskript for å sikre overføring av data være sentral i denne epicen.

In scope

Out of scope

No response

Additional Information

No response

Ta utgangspunkt i bygg/deploy script for Altinn.Broker og gjør tilsvarende for Correspondence med tanke på DEV slik at vi kan begynne utvikling og testing på dev-image.

• Bygg av kodebase
• Docker-oppsett

Det må analyseres hvilke behov som må møtes av API for mottak av meldinger
Antatte funksjoner er:

• GetCorrespondence - I gml. løsning ble dette markert som "lest", bør vi heller ha en annen status som indikerer "fetched", som ikke påvirker filtre (tilsvarende slik Broker FileTransfer har "Downloaded" vs "Confirmed")
• GetCorrespondences - må ha støtte for filtrering og paginering
• DownloadAttachmentData
• MarkAsRead
• Confirm
• Archive
• Delete

Disse operasjonene vil være begrenset til autorisert mottaker av meldingen.

Vi må få inn en boks som sier noe sånn som:

Som avsender må dere være klar over at det finnes virksomheter som ikke har registrert de nødvendige rollene i Enhetsregisteret for å få tilgang til taushetsbelagt post i Altinn. Dette gjelder virksomheter som IKKE har minst en av følgende roller registrert;

Daglig leder

Styret leder

Innehaver

Bestyrende reder

Deltaker med fullt ansvar registrert på fnr*

Deltaker med delt ansvar registrert på fnr*

Virksomheter som ikke har tilgang til taushetsbelagt post i Altinn, må ved henvendelse til avsender kunne få tilbud om å motta brevet på annen måte, f.eks som vanlig papirpost.

Se til arkitekturprinsipper her: https://digdir.sharepoint.com/:w:/r/sites/PGMeldingsutveksling/Delte%20dokumenter/General/Altinn%20migrering/Melding/Altinn%203%20Correspondence%20Solution%20Architecture.docx?d=w42de20c03a1642f1b6a822d960058b53&csf=1&web=1&e=Id3dqi

Noen momenter - sporbarhet, mulig å kjøre standalone, alternativ lagring, kostnadseffektivitet, skalerbarhet, ytelse. Runtime (logisk samle tjenesten for kostnadskontroll og forvaltningshensyn).

• alt må kunne telles og fordeles pr tjeneste/tjenesteeier og på lagring/transaksjoner
• SLA 99,9 og kort "time to restore"
• Mekanismer for å kunne handtere informasjonssikkerhets og personvernhendelser

Lag en skisse for API som skal håndtere opprettelse av masseforsendelser på en enkel måte.
Basic konsept:

• 1 request
  • 1 mal-versjon av Meldingsinnhold/content med blant annet:
    • MessageTitle/MessageSummary/MessageBody som maler
    • Attachment begrenset til Shared Attachment
  • Liste med x Recipients
• Konsekvens bør bli x antall Correspondence med innhold med erstattetde mal med tilhørende notifications.

Vurder om dette blir en egen controller/datastruktur med "MassCorrespondenceOrder" osv, eller om det holder å gjøre det som en bulk-operasjon på Correspondence-kontrolleren med en grense på feks 500 recipients per request.

Datauttrekk må analyseres

Description

Epic skal fokusere på å støtte tjenesteeier fra enkel onboarding til verdi gjennom produktets livssyklus. Vi skal legge til rette for at tjenesteeiere mottar relevant informasjon på en effektiv måte, og på deres foretrukne plattformer, når de trenger det. Vi skal tilby muligheten til å enkelt kunne tilpasse bruken av våre tjenester til sine unike behov.

In scope

No response

Out of scope

No response

Additional Information

No response

Ta utgangspunkt i operasjonen InitalizeCorrespondence i CorrespondenceController og opprett initiell database og dal-kode for å lagre Correspondence i databasen for denne operasjonen.
Benytt tilsvarende metodikk som brukt i Altinn.Broker for InitializeFileTransfer,

• Intern entitet for Correspondence opprettes i prosjekt Altinn.Correspondence.Models
• CommandRequests i Altinn.Correspondence.Application
• Mapping-kode i Altinn.Correspondence.API mellom Initialize*ext og CommandRequest
• Databasemodell for Correspondence opprettes i prosjekt Altinn.Correspondence.Persistence

CorrespondenceStatus = Initialized,
I denne versjon lagres dataene rått, business logikk kommer i en senere issue.

Det er en fordel om denne implementeres etter #44 da man kan gjenbruke deler av Attachment-operasjonen.

Ta utgangspunkt i operasjonen InitalizeAttachment i AttachmentController og opprett initiell database og dal-kode for å lagre Attachment i databasen for denne operasjonen.

Denne metoden benyttes når man skal opprette vedlegg som kan deles på tvers av mange correspondence, men man kan delvis gjenbruke det i InitializeCorrespondence, så det er nok en fordel at denne implementeres før #43

Benytt tilsvarende metodikk som brukt i Altinn.Broker for InitializeFileTransfer,

• Intern entitet for Attachment opprettes i prosjekt Altinn.Correspondence.Models
• CommandRequests i Altinn.Correspondence.Application
• Mapping-kode i Altinn.Correspondence.API mellom Initialize*ext og CommandRequest
• Databasemodell for Correspondence opprettes i prosjekt Altinn.Correspondence.Persistence

AttachmentStatus = Initialized,
I denne versjon lagres dataene rått, business logikk kommer i en senere issue.

Kan du/dere hjelpe oss med noe statistikk på meldinger sendt som Taushetsbelagt Post fra NAV ? ServiceCode 5828, ServiceEdition 1

Vi henter status fra Altinn 3 dager etter utsending for å se om vi skal sende en påminnelse. men vi fanger p.t ikke opp meldinger som leses i etterkant.

Har dere mulighet til å hente ut

1. antall meldinger sendt som Taushetsbelagt Post fra NAV
2. hvor mange av disse er lest
   a. om mulig fordelt på hvor mange dager etter utsending de er lest

Våre tall:
Vi har fom 15/1 tom 20/1 sendt 4690 meldinger, og 1108 av disse var lest i løpet av de tre første dagene etter utsending.
Fom 21/1 tom 23/1 har vi sendt 1746 meldinger, men disse har vi ikke kontrollert lest-status på enda.

Taushetsbelagt post har jo ASF som tjenesteeier. Kan avsendervirksomheter autoriseres til å bruke tjenesteierAPIer for å sjekke status?

Teamet har behov for en gjennomgang av as-is correspondance.
Presentasjon av ;

• Use-case, inkludert større produkter som DPV.
• Tjenester
• Volum.
• API; SOAP / REST, TE/SB
• Batch
• Lesebekreftelser
• Varsling / revarsling.-

Description

Målet med denne epic er å muliggjøre effektiv kommunikasjon mellom tjenesteeier og deres brukere/ konsumenter. Her samler vi alle oppgaver som handler om å sende meldinger. Epic omfatter både det å legge grunnlaget for en fleksibel meldingsinfrastruktur, opprettelse av meldinger, detaljert oppfølging og administrasjon av utsendelser.

In scope

No response

Out of scope

No response

Additional Information

No response

Tasks

• #24
• Støtte for varsling oppsett for instans/ forsendelse
• Funksjonalitet for å finne informasjon om mottaker
• API for å forespørre status
• Støtte en til en
• Støtte en til mange forsendelser
• Støtte events (publisering)
• Slette forsendelse/ korrigere feil i utsendelser
• Tilby støtte for instansiering via eFormidling
• GUI for å forespørre på status
• Angi gyldighet for meldingen som grunnlag for sletting (valid to/from)
• [ ]

Vi må avklare hvordan samspillet mellom Altinn 2 og Altinn 3 skal være i en overgangsfase.

Noen ting som må drøftes of besluttes:
Behov for å vise A2 meldinger i A3 arbeidsflate.
Behov for å tilgjengeliggjøre A3 innhold i A2-api

Issue for avklaringog vurderinger knyttet til og implementering for migrering av data (hoveddsaklig meldinger men også metadata) fra Altinn 2 til Altinn 3.

Må avklares med Bjørn og Eirik mtp samspill med dialogport/arbeidsflate og sentrale føringer.

Prinsipp: En sluttbruker skal ikke "miste" meldinger som en følge av overgangen. Altinn 2 elementer må vises i Altinn 3.
JUS: Frem i tid så kan vi sette vilkår for sletting men bruker må være informert om dette.

Vi har inviterte eksisterende brukere til en-til-en møter for å samle innsikt. Innsikten skal hjelpe oss med å identifisere potensielle utfordringer og behov som skal adresseres under migreringsprosessen, krav til MVP og fremtidig løsning. Vi må derfor lage en intervjuguide som vil gi en strukturert tilnærming til datainnsamling fra brukerne.

This issue lists Renovate updates and detected dependencies. Read the Dependency Dashboard docs to learn more.

Awaiting Schedule

These updates are awaiting their schedule. Click on a checkbox to get an update now.

• Update dockerfile non-major dependencies (mcr.microsoft.com/dotnet/aspnet, mcr.microsoft.com/dotnet/sdk)
• Update nuget non-major dependencies (Azure.Extensions.AspNetCore.Configuration.Secrets, Azure.Identity, Azure.Messaging.EventGrid, Microsoft.AspNetCore.Authentication.JwtBearer, Microsoft.AspNetCore.Mvc.Testing, Microsoft.AspNetCore.OpenApi, Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.Design, Microsoft.EntityFrameworkCore.InMemory, Microsoft.Identity.Web, Npgsql.EntityFrameworkCore.PostgreSQL, OneOf, Swashbuckle.AspNetCore)
• Update azure/arm-deploy action to v2
• Update resource Microsoft.App/containerApps to 2024-03-01
• Update resource Microsoft.App/jobs to 2024-03-01
• Update resource Microsoft.App/managedEnvironments to 2024-03-01
• Update resource Microsoft.App/managedEnvironments/storages to 2024-03-01
• Update resource Microsoft.DBforPostgreSQL/flexibleServers to 2022-12-01
• Update resource Microsoft.DBforPostgreSQL/flexibleServers/administrators to 2022-12-01
• Update resource Microsoft.Resources/resourceGroups to 2024-03-01
• Update resource Microsoft.Storage/storageAccounts to 2023-04-01
• Update resource Microsoft.Storage/storageAccounts/fileServices to 2023-04-01
• Update resource Microsoft.Storage/storageAccounts/fileServices/shares to 2023-04-01
• Update tj-actions/changed-files action to v43

Detected dependencies

• Check this box to trigger a request for Renovate to run again on this repository

Ukentlig uttrekk på alle correspondance-tjenester som gir oversikt over åpnet/uåpnet pr tjenesteeier/avsender

Setup Test project for Correspondence.
Use setup from broker to test all API calls.

Description

Målet er å sikre at meldinger ikke bare blir håndtert på en sikker og effektiv måte, men også bidra til at de er lett tilgjengelige og håndterbare for mottakeren. Denne epic forkusere ikke bare på det tekniske, men også brukeropplevelsen som skal realiseres i andre brukerflater. Vårt mål er å bidra til å understøtte at mottak, visning, og administrasjon av meldinger er så smidig og problemfritt som mulig, samtidig som vi opprettholder høye standarder for sikkerhet og personvern.

In scope

Avklare med dialogporten - hva skal/må de ha - hvilke behov løses av dialogporten og hva må løses av oss?

Out of scope

No response

Additional Information

No response

Dialog med POD er veldig viktig. Blant annet er det viktig at vi tidligst mulig får avklart at våre juridiske vurderinger er i tråd med deres. Et viktig punkt er blant annet at vi legger lik tolkning av schrems II til grunn, sånn at det ikke er uklarheter om hvilke tiltak som er nødvendige for å sikre overføring av personopplysninger.

Er i kontakt med Mohammed Heddad, som er vår tildelte kontaktperson for videre diskusjon og dialog rundt ny "straffesaksforsendelse". Prøver å få til et møte med POD i midten av august med POD sitt juridiske miljø.

Siste kontakt 31. juli

Legger til Oddhild som ansvarlig for at hun er oppdatert og klar for møte med POD når det blir aktuelt.

Behov for uttrekk som viser orgnr. som ikke har hovedadmin. I praksis de som ikke har følgende rolle registrert:

Description

onjn

Additional Information

No response

Tasks

No response

Acceptance Criterias

No response

Altinn melding må evne å ta i mot og sende meldinger fra/til eFormidling, (DPI, DPV) og KS Fiks.

Kan dette løses med at vi setter opp en Peppol Access punkt, eller er det mer hensiktsmessig med direkte (legacy)-integrasjoner mot disse for så å gå mer rett mot en målarkitektur?

I første omgang brukes denne featuren for analyse, og avklaringer mot eFormidling og KS Fiks hvor det er ønskelig med en relativt grundig utredning av løsningsalternativer, fordeler og ulemper (inkl kostnader), på kort og litt lengre sikt.

Viktige rammer: Politiske føringer, PG strategi, EU, og hva som er praktisk mulig.

Det langsiktige bildet kan flyte litt men hvordan vi løser dette på kort sikt (i 2024) må være avklart før sommeren.

Description

Denne epic er for å etablere og samle issues knyttet til infrastruktur og tilrettelegging for ikke funksjonelle krav som sikkerhet, personvern, arkitekturprinsipper osv.

Det er viktig at vi etablerer en robust og skalerbar infrastruktur som kan støtte opp om nye fremtidige behov knyttet til endringer i personvern, volum etc. Denne epic vil sikre at vi ikke kun støtter de funksjonelle behovene til brukerne, men at vi kan tilby høy kvalitet på alle paramenter gjennom hele systemet levetid.

In scope

Etterlevelse av lovkrav
https://docs.altinn.studio/technology/architecture/principles/

Målet er å adressere og samle alle relevante issues som er knyttet til utforming og implementering av teknisk infrastruktur og tilrettelegging for ikke-funksjonelle krav. Dette inkluderer, men er ikke begrenset til, sikkerhet, personvern, ytelse, tilgjengelighet, og overholdelse av relevante arkitekturprinsipper og standarder.

Out of scope

No response

Additional Information

No response

Det må etableres REST-API som tilrettelegger for mottakere av correspondence.
I tillegg til metoder som lar dem hente ned enkeltmeldinger og vedlegg, må det være liste-funksjoner med filtre som lar dem gjøre enkelte søk, samt metoder for å oppdatere statuser.

Vi ønsker å etablere kontakt med de fem mest utbredte systemleverandørene advokatene benytter seg av, mot slutten av august.

Er i kontakt med Vegard Fløtre, fra Advokatforeningen. Han peker på TechTorget.no som sin partner.

Avklare hva vi kan bruke de til fremover i vårt arbeid.

Støtte NAV med informasjon for å forberede skalering av deres "taushetsbelagt"-tjeneste

Selve meldingsinnholdet (minus title og summary, og metadata som avsender og mottaker) skal ligge i messagebody som vil fungere som et "generisk" vedleggsformat med rammer som sikrer embedded visning av innhold i arbeidsflate og ev. andre SBS.

Vi må vurdere om vi skal ha noen standard GUI-komponenter i message body eller metadata - slik som for eksempel en mulig standardtekst som sier noe om hvor lenge meldingen (vedlegget) vil være tilgjengelig basert på lagringstid konfigurert av avsender/tjenesteeier. Dette bør muligvis ligge på nivået over..

Er MIME/type nok? - json, xml, html, txt?!

Informasjonssikkerhet: sensitivt innhold som vises fra messagebody - trafikk mellom correspondance og arbeidsflate for å hente innhold må være sikret på tilbørlig vis.

Mulig å skru på logging her? Negative virkninger?

Taushetsbelagt post er ikke tilgjengelig for de virksomhetene som ikke har hovedadministrator som kan delegere rollen til noen. ANS/DA uten daglig leder tog med juridiske personer i deltakerrollen treffes her (de kan ikke åpne posten sin).

Det har gått en dialog med bla helsetilsynet og NPE rundt dette og vært endel negative uttalelser fra legestanden.

Vi trenger å trekke ut mest mulig historisk data fra vår gamle Altinn plattform i tilknytting til correspondance for å forstå bruksmønstre, volumer og andre relevante indikatorer. Denne dataen vil gi oss viktig innsikt til vår migreringsstrategi, og vil også kunne være nyttig for å identifisere eventuelle forbedringsområder.

Type data som vi snakket om i møte
Volum: Antall sendte, mottatte, arkiverte meldinger osv.
Meldingstyper: Kategorier av meldinger som er sendt eller mottatt (f.eks. fakturaer, påminnelser, informasjonsmeldinger, varsling, skjema...).
Interaksjoner: API-oppslag, frekvens av ulike funksjoner brukt, etc.
Feil og hendelser: Typiske systemfeil, brukerfeil eller andre viktige hendelser.

Issue for analyse og avklaringer rundt hvordan vi kan løse parallell kjøring av A2 og A3 meldingstjenester fra Q4 2024 til Q2 2026.

MÅL: Tjenesteeiere og SBS skal ha størst mulig frihet (migreringsvindu) og minst mulig arbeid i sin overgang fra A2 til A3.

Vi kan ikke forvente å få avklart ALT i den første runden men vi må avklare tilstrekkelig til at vi kan starte bygging, og informere utad i god tid før sommerferie.

Lag en førsteutgave av API-spesifikasjon som skal dekke CreateCorrespondence.
Ta utgangspunkt i Altinn 2 modellene for CreateCorrespondence og juster for behov og modernisering, forenkle der mulig.

• Inkluder:
  • Notifciations basert på mal
• Out-of-scope:
  • SDP/DPI

Definition of Done:

• API-spesifikasjon (Swagger/OpenAPI) tilgjengeligjort i repo

Ref innspill på Slack: https://altinn.slack.com/archives/C068VA4SXFD/p1713525912405089?thread_ts=1713522323.522449&cid=C068VA4SXFD

Endre LanguageCode til å være "Language" og benytte ISO 639-1.

Oppdater API Spec på Correspondence og sjekk API for Broker om det er tilsvarende tilsvarende problem på PropertyList.

Som tjenesteeier/utvikler ønsker jeg ett UI å forholde meg til for oppsett, og oppfølging av mine tjenester, slik at jeg har god kontroll og oversikt på den.

Noen ting å tenke på:
Samle UI-aspekter av design/configtime for correspondance i studio:

• RR (gjenbruk fra apps?)
• RRR
• Instansieringskontroller
• Monitorering og lenker til andre relevante forvaltningsverktøy
• Migreringsverktøy?
• Egen sidemal for correspondance i studio
• Templates kan bo her?
• Skille på service designer og service management

Må analyseres og så prioriteres.

En enkel justering av CorrespondenceStatus bør gjøres etter noen ytterligere avklaringer.
Juster status til:

• ChangedBySender- (ChangedByGovAgency i A2) -Ikke i bruk - Slettes
• ChangedByRecipient - (ChangedByUser i A2) - Ikke i bruk - Slettes
• MarkedUnRead - Kan fjernes da det er en gammel hack.

Legg til status:

• Error - Feilet under intialisering/validering.

Insiksfasen og konsept for ny meldingstjeneste omfatter:
Forstå bruk, behov og identifisere forbedringspunkter som er innenfor rekkevidde.
Avklare samspillet og scope med dialogporten, varsling, lagring, autorisasjon, arbeidsflate, eformidling og dpi.
Definere leveransene for melding, og lage utgangspunkt for migreringsstrategi.

Det må opprettes et REST API for å opprette meldinger som skal sendes til mottakere.
Analysejobb (løsningsarkitektur) for å se på API-ene samlet - behov for nye API-er? Vurder spesielt nytt API for å støtte flere maler/meldingstyper, i tillegg til dagens CreateSimpleCorrespondenceService
Alle API må spesifiseres med Swagger/OpenAPI og ut på høring før de implementeres.