Endre dialog-modell mht innholdsfelter (body, title etc) og innfør "summary"

[elsand]

Det er behov for å kunne vise tekst i listevisningen som indikerer hva som skal skje. Dette er noe som typisk vil ligge i "body", men det er behov for å holde teksten i listevisningen kort (~200 tegn) og konsis.

Som diskutert i møtet 24. okt ønsker vi å future-proofe bruken av fritekster i dialoger, og samtidig definere klarere "typer" av tekster som har ulike formål i stedet for en diger "body" som brukes til alt muliog

Det foreslås av DTO-ene utvides med noe ala:

{
// ...
    "content": [
        {
            "type": "Title",
            "content": [ { "cultureCode": "nb_NO", "value": "Et eksempel på en tittel" } ],
        },
        {
            "type": "Summary",
            "content": [ { "cultureCode": "nb_NO", "value": "Et sammendrag her. Maks 200 tegn, ingen HTML-støtte. Påkrevd." } ],
        },
        {
            "type": "AdditionalInfo",
            "content": [ { "cultureCode": "nb_NO", "value": "Noe tilsvarende 'body' i dag (enkel HTML-støtte, inntil 1023 tegn). Ikke påkrevd" } ]
        }
    ] 
}

Dette gir oss mulighet til å

• statisk (i kode) konfigurere hvilke typer som skal inkluderes i liste-DTO-er
• la frontend rendre de forskjellige typer tekster ulikt
• definere ulike valideringsregler (påkrevd/valgfri, html eller ikke, maks lengde etc) per type
• legge på flere types etter hvert (footnote, next-step-description, simple-feedback-form)
• potensielt legge på mulighet for å bestemme/overstyre plassering (overridePlacement: "after-buttons")

Tekniske detaljer

• Ny IEntity med dependent relationship til DialogEntity
• Ikke egne endepunkter, men kan delvis oppdateres med PATCH tilsvarende actions

Innholdstyper (HTML-regler som definert i #30)

Type	Påkrevd	Maks tegn	Skal rendres som HTML?	I liste-DTO?
Title	Ja	200	Nei	Ja
SenderName	Nei	200	Nei	Ja
Summary	Ja	200	Nei	Ja
AdditionalInfo	Nei	1023	Ja	Nei

Tasks

Preview Give feedback

1. Lage konfigurasjoner per "content-type" statisk i kode, se over
2. Lage validatorer per type, se over
3. Ny tabell, og migreringer (nuke eksisterende dialoger)
4. Oppdatere DTO-er og mappings
5. Se på å eksponere et GET-endepunkt som utgir "dialogcontent-type" konfigurasjoner
6. Flytte title og senderName inn i content

Tidligere innhold i denne issuen

Her er det noen ulike muligheter:

1. Eksponere "body" i listevisning også. Dette er det enkleste, men gir minst fleksibiltet. Det øker også datamengden som overføres i lister. Frontend kan da velge å rendre et utdrag av dette (f.eks. noe som fader ut). Risikerer at tekst brytes på ukurante steder.

2. Utvide Dialog-modellen med et eget påkrevd "Summary"-felt, og eksponere dette på både liste og detalj-modellene. Dette kan da ha andre begrensninger på lengde/format (f.eks. ikke tillate HTML). Gir mest fleksibiltet, men er også mer jobb for tjenesteeiere. Gir oss bedre kontroll mht rendring av lister, og kan evt. velge å vise summary som en ingress-tekst på detaljvisningen.

3. Som 2, men gjør Summary valgfritt. Listevisningen vil da i praksis kun ha tittel hvis det ikke oppgis.

Jeg heller mot 3. Tanker?

[ingefossland]

Jeg tenker det er et poeng at teksten som vises i lister og søk er den samme som dukker opp inne i selve dialogen, og heller mot å eksponere body-innholdet. Men i lister og søk trenger man bare dette som ren tekst, så ideelt sett kanskje et eget felt
hvor evt. html-tags fra body er vasket bort?

[elsand]

Det er jo ikke noe i veien for å vise summary-feltet i detalj-visningen også. Men "body"-feltet vil jo kunne inneholde mye informasjon, som kan være uhensiktsmessig/rotete og vise i listevisningen. Det å vaske HTML-en og/eller lage automatiske utdrag er vanskelig å få til å fungere godt. Det vil være støtte for å oppgi tag-ene: p, a, br, em, strong, ul, ol, li, og å bare fjerne HTML-en vil fort ende opp med noe som blir ganske uleselig. Tror det da kan bli vanskelig for tjenesteeiere å populere body på en måte som fungerer godt både i liste og detalj-visningene.

[elsand]

@ingefossland @alexdigdir @MagnusSandgren @oskogstad

Har oppdatert denne issuen ref. diskusjonene i åpent forum i dag. Farbar vei?