Open gtcno opened 3 years ago
Nyttige lenker: https://confluence.adeo.no/display/TDP/3.9.1+Dagpenger+ut+av+henvendelse+og+dialogstyring https://confluence.adeo.no/display/TS/Veien+videre+for+felleskomponentene+Henvendelse+og+dialogstyring# https://confluence.adeo.no/display/TS/Dialogstyring https://confluence.adeo.no/display/TS/Henvendelse#
Dette virker foreløpig som en dårlig løsning, med tanke på kortsiktigheten. Vil ikke ende opp med ny case av søknadsdialog.
Skjønner ikke helt hva dette innebærer? Minner om punktet nedenfor, men mtp. at det står kopiere det som er gjort virker det som at vi skal forke den midlertidige løsningen, noe som virker lite gjennomtenkt.
Hør med digisos (de har skrevet seg ut av faktum-modellen)?
Opprett behandlingsId + faktumstruktur i selve sendsoknad fremfor å la henvendelse gjøre det. Mellomlagring osv må håndteres ett annet sted også
Hvordan skal man løse gjenoppta søknad? (Fortsette på en mellomlagret søknad) -> trengs å vises på dittnav at det er påbegynte søknader
Hvordan skal man løse ettersendelse? (Sende inn vedlegg på en allerede innsendt søknad) -> trengs å vises på dittnav at det er innsendte søknader, kunne se hvilke vedlegg som mangler, hvilke vedlegg som er sendt inn, endre vedlegg som er sendt inn, kunne legge til ekstra vedlegg som ikke kreves
arkiveringsløp?
Håndterer per nå at brukere laster opp flere filer per vedlegg. Kan kresje sendsoknad-biten når det blir kjempestore filer som konsolideres per vedlegg.
bruker starter søknad -> soknadsdialog -> henvendelse oppretter faktumstruktur og behovsid og mellomlagrer dittnav viser dagpengesøknader -> Saksoversikt -> henvendelse (metadata om søknad)
alternativ -> skrive om frontend til react, fjerne faktumstrukturen, lage logikk for verifisering av spørsmålene selv, sende svar tilbake til backend i blob. (Hvordan gjør vi det med migreringer og bakoverkompabilitet?)
tldr: stor oppgave
Må uansett gjøre om soknadsdialog sin backend om til å opprette id og faktumstruktur, uansett hvilken løsning vi går for. Dette krever i tillegg til at vi sender inn metadata til henvendelse slik at mittnav og mine saker vil fortsatt fungere
søknadsteamet som laget kontantstøtte fra scratch (gikk over til foreldrepenger) gjorde det ganske greit, få litt erfaringer fra dem?
Vi må ha: Lagring Logikk for innsending Logikk for å hente mellomlagrede søknader Logikk for å sende inn vedlegg på innsendte søknader (hvor lenge kan man ettersende? når kan man ettersende?) Logikk for å lagre søknader Logikk for å hente ut lagrede søknader
Henvendelse / dialogstyring: Planen var å slå av sommer 2021, går nok ikke pga covid og kobling til dialogstyring når teamsoknad er ut av henvendelse har dagpenger største koblingen til henvendelse. innen 2022 vil ikke teamsoknad drive vedlikehold av henvendelse da de etter planen vil ha skrevet seg ut
Hvordan bli kvitt de 11 konsumentene av henvendelse? Ønsker at dagpenger har dataene hos seg selv/sender som en strøm selv.
dittnav saksbehandlere?
Grunnen til at det lagres i henvendelse er et tidligere sikkerhetskrav som ikke lenger er gyldig. Er derfor ingen grunn til å ikke lagre/opprette søknadsid og faktumstruktur på egenhånd i soknad-server
Anbefaling Sturle: bli kvitt mellomlagring/opprettelse av søknadsid fra henvendelse, og gjør dette i soknad-server deretter skriv om hele dritten og koble seg vekk fra faktumstrukturen. -> finn en måte å la avhengige konsumenter både få vite om og hente ut informasjon direkte fra oss.
Konklusjon møte internt dagpenger: Me to Everyone (10:41 AM) Soknadsdialog vil leve lengre enn henvendelse slik det ser ut nå Lage to bets: overta heiv/dialogstyring, lage nye komponenter Finne ut hva henvendelse/dialogstyring gjør Me to Everyone (10:42 AM) Finne ut hva som er viktig for soknadsdialogen å gjøre, hva som trengs av andre systemer i nav
tldr: stor oppgave
Team Søknad har en ny Henvendelse og Dialogstyring verdikjede. De vil at vi skal migrere til denne verdikjeden.
VI må finne ut hvordan denne verdikjeden brukes i dag. Denne analysen skal brukes som et hjelpemiddel til å bestemme om vi skal
a) Migrere til ny verdikjede b) Forke og overta den gamle verdikjeden c) Lage noe eget.