Flere begrunnelser v1 - Oppdatert IM modell og PDF støtte

[Jesper-Hustad]

Lager en draft da det blir mye kode å se på om hele funksjonen skulle vært klar for prod.

Funksjonen Flere begrunnelser legger til støtte for flere inntekt endring begrunnelser (List<endringsAarsak>)

For å støtte dette i prod beholder vi den gamle verdien slik at frontend ikke må endres og vi unngår inflight errors.

Endringer:

0: I denen versjonen har jeg oppdatert IM modellen til hagDomeneInntektsmeldingVersion=0.1.8-SNAPSHOT
Denne beholder gamle endringsAarsak variabelen og legger til en nullable liste med deafult verdi = null

data class Inntekt(
    val beloep: Double,
    val inntektsdato: LocalDate,
    val naturalytelser: List<Naturalytelse>,
    val endringAarsak: InntektEndringAarsak?,
    val endringAarsaker: List<InntektEndringAarsak>? = null, // <-- lagt til denne
) {

1: Listen blir utfylt når vi serialiserer JSON til Inntektsmelding med en util funksjon
(siden den blir satt til null om den ikke eksisterer i JSON)

// midlertidlig duplisering for å støtte flere endringsÅrsaker
fun SkjemaInntektsmelding.fyllUtMangledeEndringsAarsaker(): SkjemaInntektsmelding {
    val medEndringsAarsakerfyllt = this.copy(inntekt = this.inntekt?.copy(endringAarsaker = listOfNotNull(this.inntekt?.endringAarsak)))
    val verdiMangler = this.inntekt?.endringAarsaker.isNullOrEmpty()
    return if (verdiMangler) medEndringsAarsakerfyllt else this
}

3:
I PDFen så er det lagt til støtte for flere begrunnelser
(snakket med Dag om å bytte til Endingsårsak (1 av 2) teksten)

val endringAarsaker = inntektsmelding.inntekt?.endringAarsaker.orDefault(emptyList())
val antall = endringAarsaker.size
endringAarsaker.forEachIndexed { indeks, endringAarsak ->

    forklaringEndring = FORKLARING_ENDRING + if (antall > 1) " (${indeks + 1} av $antall)" else ""
    when (endringAarsak) {
        is Bonus -> addBonus()
        is Feilregistrert -> addFeilregistrert()
        //....
    }
}

PDF:

[mortenbyhring]

Kan gjerne fjerne utkommentert kode, heller ta det inn når det faktisk skal tas i bruk

[mortenbyhring]

Veldig bra og informativ PR. Jeg er fortsatt litt i tenkeboksen på om vi bør lage en ny versjon eller ha to felter slik som nå - og så må vi pønske litt på hvordan vi skal sikre bakoverkompabiliteten for eksisterende payloads

[Jesper-Hustad]

Enig at vi må planlegge mer på dette. Tar en prat imorgen 👍

[Jesper-Hustad]

Denne eksisterer for å kunne teste at teksten kommer i PDFen

[Jesper-Hustad]

Denne testen med alle mulige parvise kombinasjoner tar ca 1.8 sekunder på min datamaskin. Vet ikke hvor nødvendig den er. Tanken er å fange om det er to par av begrunnelser som ødelegger for hverandre

[mortenbyhring]

Hvordan kan de egentlig ødelegge for hverandre?

[Jesper-Hustad]

Er vel egentlig ikke mulig slik koden er idag. Men tanken er om to begrunnelser bruker en felles variabel eller metode med PDF produksjonen som skaper trøbbel når de kjører sammen kan denne testen fange den feilen.

[Jesper-Hustad]

Her er løsningen på å ikke legge til en mutable verdi.

Kan argumenteres at den er egentlig mer oversiktlig.

Øverste del kan forenkles til:

when (endringAarsak) {
      is Bonus, is Feilregistrert, is Nyansatt, is Ferietrekk ->
            addLabel(forklaringEndring, endringAarsak.beskrivelse())

[mortenbyhring]

Fint å slippe mutable! 👏

[mortenbyhring]

Disse skal vel swappes igjen for å kjøre tester i bygget

[mortenbyhring]

Bør bygge en final release (uten snapshot) som brukes her, før vi merger

[mortenbyhring]

Kan vel droppe println og assertSoftly egentlig?

[mortenbyhring]

Kanskje ha et annet navn en fyllUtManglede - noe mer som ala "konverterEndringAarsakTilListe"
Og så tror jeg det kan være greit å sjekke at endringAarsaker er tom, før man gjør dette. Da slipper vi å holde styr på når frontend evt endres.