Etablere API for opprettelse / endring / sletting av dialoger/aktivitetshistorikk

[elsand]

Tasks

Preview Give feedback

1. Implementere POST-endepunkt for opprettelse av dialog
2. Implementere PUT-endepunkt for endring av dialog
3. Implementere DELETE-endepunkt for sletting av dialog
4. Implementere validering av forespørsel om opprettelse
5. Implementere validering av forespørsel om endring
6. Håndtere oppdateringer på dialoger som har datoer i fortid (og dermed vil treffe "er i fremtid"-valideringsregler)

Vi legger opp til at alle opprettelse/oppdateringer som gjøres på "barne-entiteter" (pt. er det ikke definert noen) skal håndteres på samme måte som PUT på aggregatet, slik at vi kan ha én Update-kommando i applikasjonslaget.

Valideringsregler

• Nullable felter i ER-diagrammet er valgfrie
• CreatedAt/UpdatedAt/DeletedAt skal ikke kunne oppgis i POST/PUT men utledes av Dialogporten. Unntaket er CreatedAt på DialogActivity.
• Id er valgfri, og det skal genereres en monotisk UUIDv7 hvis ikke oppgitt. Hvis oppgitt skal den være en gyldig UUID (hvilken som helst versjon)
• ExpiresAt er valgfri, må være i fremtiden
• DueDate må være i fremtiden, og før ExpiresAt
• VisibleAt må være i fremtiden, og før DueDate og ExpiresAt (se også Håndtere bruk av VisibleAt ved event-generering #110)
• VisibleAt skal ikke kunne endres (fjernes fra UpdateDTO)
• Body skal kunne rendres som HTML, og skal valideres til inneholde et begrenset subset:
  • Tags: p, a, br, em, strong, ul, ol, li
  • Ingen attributter på noen tags skal støttes, med ett unntak; href på a
  • href må begynne med https://
• Org skal ikke kunne oppgis, men utledes av token (settes til dummy-verdi inntil Implementere autentisering og autorisasjonskontroll for tjenestetilbydere #44 er implementert)
• Party skal starte med enten /org/ eller /person/ og inneholde hhv et organisasjonsnummer eller et f-eller d-nummer. Kun sjekk well-formed-ness (mod 11-sjekk for orgnr og f/dnr)
• ServiceResource må ha prefiks urn:altinn:resource:, og identifikatoren må matche en ressurs som finnes i ressursregisteret (se API)
• Sjekk at evt. oppgitte relatedDialogElementId enten finnes i request payload, eller finnes i databasen ved update
• Sjekk av evt. oppgitt relatedActivityId / dialogElementId i activity enten finnes i request payload, eller finnes i databasen ved update
• Sletting av dialogelementer som refereres til av actions skal nektes (restrict)
• Sletting av dialogelementer som refereres til av andre dialogelementer skal godtas; referanse settes til null
• Sletting av dialogelementer som refereres til av aktiviteter skal godtas; referanser settes til null
• activityExtendedType og dialogElementType skal være gyldige URI-er (sjekk med Uri.IsWellFormedUri(uri, UriKind.Absolute)
• Hvis sunsetDate oppgis, må deprecated være true

Autorisasjon

Se #44

Akseptansekriterier

GITT en førespørsel til Dialogporten
NÅR forespørselen er en POST på dialog-endepunktet
SÅ skal forespørselen autoriseres og valideres jf kravene over
OG createtAt settes til gjeldende tidspunkt
OG lagres i databasen
OG returnere 204 Created, med GUID for den opprettede dialogen som en JSON-streng i body og en Location-header til dialogen

GITT en førespørsel til Dialogporten
NÅR forespørselen er en PUT på dialog-endepunktet
SÅ skal forespørselen referere en dialog som allerede eksisterer
OG valideres jf kravene over
OG aktivitetshistorikken må være tom (denne kan ikke overskrives)
OG updatedAt settes til gjeldende tidspunkt
OG endringen lagres i databasen
OG returnere 200 OK med Location-header til dialog

GITT en førespørsel til Dialogporten
NÅR forespørselen er en PUT på dialog-endepunktet og det oppgis en If-Match header som ikke matcher ETag på dialog
SÅ skal forespørselen feile med 412 Precondition Failed (se #109)

GITT en førespørsel til Dialogporten
NÅR forespørselen er en DELETE på dialog-endepunktet
SÅ skal forespørselen referere en dialog som allerede eksisterer
OG vallideres jf kravene over
OG deletedAt settes til gjeldenden tidspunkt samt deleted=true

[elsand]

Håndtere oppdateringer på dialoger som har datoer i fortid

Som diskutert må vi ha andre valideringsregler for dette på update vs create. Create kan løses gjennom nivå 2-regler (IsInFuture()) mens update må forholde seg til det som allerede ligger i databasen (nivå 3) og sjekke om den er forsøk endret.