TFP-6069: V2 API for brev

[mrsladek]

Først og fremst behandling, fagsak, resultat og verge - noe som alltid hentes for alle type brev.
Vi kjører expand kontrakt i formidling og sammenligner svar.
På sikt kan vi frikoble oss fra APIet som deles med frontend og fptilbake og starte med forenkling.

[jolarsen]

Hovedproblemet er at lenker + Dtos brukes av både frontend og formidling (og tilbake)
Ressurslenkene er i seg selv ikke et problem - det gjelder bare å ha disjoint links til frontend, formidling og tilbake

[jolarsen]

Hva med å flytte nye ting til no.nav.foreldrepenger.web.app.tjenester.formidling ?
Hvis du beholder under behandling/dto - så er det fint om du kaller det FormidlingFagsak eller BrevFagsak - samme med de andre V2 (behandlingresultat, verge, ..). Det bør være lett å lese formålet med klassene ut fra klassenavn / package

[mrsladek]

Ja, dette er en god idé å samle alt på ett sted. Dette er fortsatt et pågående arbeid, så det vil komme flere endringer underveis.

Jeg gir beskjed når alt er ferdig utviklet men takk for innspill så langt :)

[jolarsen]

Ikke helt med på å duplisere kodeverkene - uten ref som tvinger fram vedlikehold.

• Mange er statiske
• Behandlingsårsaker - krever at man er bevisst på at den er duplisert. Vil gi feil i løpet av et års tid.

Enn så lenge så blir de serialisert som pg JsonValue.

Kan vurdere om det er verdt innsatsen med en expand-contract i retning plain enum - men tror kanskje vi skal se på noe felles kode.

Ellers bra tiltak !

[mrsladek]

Tanken med duplisert kodeverk var at man kunne flytte hele kontrakten ut til fp-kontrakter og så bruke på tvers mellom sak og formidling. Vi kan godt ha enumene duplisert og forenkle APiet først til noe som blir enklere å sentralisere.

[jolarsen]

Tanken med duplisert kodeverk var at man kunne flytte hele kontrakten ut til fp-kontrakter og så bruke på tvers mellom sak og formidling. Vi kan godt ha enumene duplisert og forenkle APiet først til noe som blir enklere å sentralisere.

Da ville jeg tenkt expand / contract: lagd plain enums med en gang og latt Dto ha to verdier/felter - en for kodeverdi-enums og en for de nye plain enumene. Når formidling er konvertert så kan kodeverdi-feltene fjernes i Dto.

[sonarqubecloud]

Quality Gate failed

Failed conditions
36.9% Coverage on New Code (required ≥ 60%)

See analysis details on SonarQube Cloud

[jolarsen]

Jeg ville gått for plain enum ganske fort - eller med en gang egentlig.
En expand/contract vil uansett kreve GammelEnum ytelseType + NyEnum yt1 i en overgangsfase.