Litt om dokumentflyt og til/fra-referanser i Nikita

[Petter Reinholdtsen]

De siste dagene har jeg implementert støtte for dokumentflyt i Nikita,
og endringen venter nå på korrekturlesing i
<URL: https://gitlab.com/OsloMet-ABI/nikita-noark5-core/-/merge_requests/331 >.

Da dokumentflyt inneholder flere brukerreferansefelt, så er det en del
nye problemstillinger jeg måtte ta stilling til, som jeg har lyst til å
lufte her.  Først litt bakgrunnsinformasjon.  PlantUML-strukturen for
dokumentflyt basert på spesifikasjonsteksten ser i dag slik ut:

  class Sakarkiv.Dokumentflyt {
    +systemID : SystemID [0..1]
    +flytTil : string
    +referanseFlytTil : SystemID [0..1]
    +flytFra : string
    +referanseFlytFra : SystemID [0..1]
    +flytMottattDato : datetime
    +flytSendtDato : datetime
    +flytStatus : FlytStatus
    +flytMerknad : string [0..1]
  }
  Sakarkiv.Dokumentflyt "dokumentflyt 0..*" *-- Sakarkiv.Arkivnotat
  Sakarkiv.Dokumentflyt "dokumentflyt 0..*" *-- Sakarkiv.Journalpost

Det betyr i korte trekk at journalpost og arkivnotat kan ha uendelig
antall dokumentflyt-oppføringer knyttet til seg, og disse består av
overnevnte felter.

Poenget med dokumentflyt er så vidt jeg forstår å dokumentere hvordan
informasjon/dokumenter i en sak har beveget seg rundt i organisasjonen
for godkjenning.  Det opprettes en slik dokumentflytoppføring når noe
skal godkjennes, flytFra og referanseFlytFra settes til navn/brukernavn
på den som ber om godkjenning og UUID for brukerinstansen til
vedkommende (tilsvarer i praksis arkivenhet.opprettetAv og
arkivenhet.referanseOpprettetAv), og flytTil/referanseFlytTil settes til
navn/brukernavn og UUID for den som skal godkjenne dokumentet.
flytSendtDato inneholder når dokumentflytoppføringen ble opprettet (i
praksis det samme som arkivenhet.opprettetDato), og flytStatus settes i
utgangspunktet til 'Ikke godkjent', som så endes til 'Godkjent' av
mottaker som også setter 'flytMottattDato' og eventuell flytMerknad.

Jeg har videre antatt at det skal være mulig å sette flytFra/flytTil til
navn som ikke har brukere, og disse vil da mangle
referanseFlyt*-verdier.  En kan altså opprette en dokumentflyt-instans
med følgende sett av verdier:

  flytFra: "Registert bruker"
  referanseFlytFra: 7130d618-5795-11ea-b20e-0fda1e8f9458

Dette vil kun fungere hvis UUID i referansen har brukernavn "Registrert
bruker".  Hvis UUID referer til annen bruker så vil Nikita avvise
opprettelsen.

En kan også opprette uten referanse:

  flytFra: "Ikke-registrert bruker"

Her kopierer jeg inn verdien men lager ingen kobling til bruker-instans
i databasen.

Et åpent spørsmål er hva som skjer hvis en oppretter med brukernavn på
eksisterende bruker men uten referanse:

  flytFra: "Registert bruker"

I mitt forslag til Nikita-endring behandles dette som ikke-registrerte
brukere og kopieres inn uten kobling til bruker-instans i databasen.
Det betyr at UUID indikerer at brukeren forventes å eksistere i
databasen.  Bør det i stedet avvises eller godtas med søk etter bruker
og kobling til bruker-instans?

For å forenkle traversering av arkivstrukturen via REST-grensesnittet,
så ønsker jeg at det finnes lenker i _links til alle relaternte
instanser i arkivet.  For dokumentflyt så er det jo tre aktuelle
instanser det bør lenkes til.  Foreldreinstansen (enten journalpost
eller arkivnotat), og brukerinstansene for flytTil og flytFra.  Til
slike trengs det unike relasjonsnøkler, og her mangler spesifikasjonen
egnet relasjon for brukerinstansene.  Foreldrelenken kan bruke
instansrelasjonsnøkkelen, da den er unikt identifiserende, men med to
brukerinstanser så ikke begge få
'https://rel.arkivverket.no/noark5/v5/api/admin/bruker/' som nøkkel.
Her tror jeg det må lages to nye relasjonsnøkler.  Hva tror dere om
'https://rel.arkivverket.no/noark5/v5/api/sakarkiv/flytFra/' og
'https://rel.arkivverket.no/noark5/v5/api/sakarkiv/flytTil/'?

En liten detalj er at tjenestegrensesnittet sier at flytMottattDato er
påkrevd, mens jeg tror den må være valgfri ved oppretting, for å kunne
sette den når mottaker godkjenner/ikke godkjenner.  Uten er det ingen
måte å skille pågående og avsluttede dokumentflyt-aktiviteter.  Ved å
gjøre den valgfri kan en flytmottaker søke etter
dokumentflyt-oppføringer der flytTil er eget brukernavn og
flytMottattDato er null for å få sin arbeidsliste.

Relatert til dokumentflyt, og implementert i Nikta for noen dager siden,
er avskrivning.  Hvis jeg forstår avskrivning og dokumentflyt riktig, så
opprettes en avskrivningsinstans for inngående korrespondanse når
utgående respons er godkjent, mens dokumentflyt opprettes for utgående
korrespondanse for å dokumentere hvordan den ble godkjent.  Dvs. at når
siste dokumentflyt for et utgående skriv er godkjent, så bør en opprette
avskrivning som knytter inngående og utgående skriv og mottaker sammen.

-- 
Vennlig hilsen
Petter Reinholdtsen