Sletting er en tematikk som kan oppfattes som vanskelig i arkiv. På den ene
siden er det ofte en holdning at man aldri sletter noe, fordi så fort du
åpner opp for sletting så kan muligheten misbrukes. På den andre siden kan det
være et reelt behov å slette noe fra arkivet fordi det er kommet inn noe i
arkivet som ikke skulle vært der. Det kan for eksempel være personopplysninger som skal
slettes etter pålegg fra datatilsynet eller dokumentasjon som er gradert
"STRENGT HEMMELIG" som ved en feil kom inn i arkivet og som må trekkes ut.
Sletting
Til en viss grad må en bruker ha kontroll over sitt eget materiale og må
ha muligheten til oppdatere og slette i arkivet. Vi kan tenke at sletting er
ofte en slags unntak, men muligheten må være tilstede for at arkivkjernen skal
oppleves som brukervennlig. Det er en vanskelig balanse mellom sikkerhet og
funksjonalitet, der funksjonalitet kommer ofte på bekostning av sikkerhet. Hvis
en bruker opplever at det ikke er mulig å slette innhold vil de kanskje velge å
arkivere så lite som mulig. Men det kommer et punkt der det er nødvendig å nekte
sletting, for eksempel når saken er avsluttet eller dokumentet er arkivert.
Uten en fleksibel tilnærmingen i tjenestegrensesnittet kan det bli vanskelig
å bygge fagsystemer på toppen av et Noark API. Det kan være fagområder som omhandler
arkivdanning som ønsker en mindre rigid kontroll av innhold og dersom tjenestegrensesnittet
skal øke omfang av bruk kan det være fornuftig å åpne for mer tillit til klient systemer.
Tilnærmingen tjenestegrensesnitt kan legge opp til kan være basert på samme som
tilnærming Ronald Reagan hadde i forhold til nedrustningsavtalen med
sovjetunionen. Den bygger på en "Trust but verify" tilnærming. En slik
tilnærming vil gi brukere mer kontroll over eget innhold, men vil trenge en
tydelig logging og sporing slik at det er enkelt å ha oversikt over hva som
skjer, spesielt med sletting.
En måte å løse dette på er at brukere kan slette dokumenter og arkivenheter
de har tilgang til, men i realiteten flyttes det over til en intern
"papir-kurv". Denne papir-kurven kan slettes av en autorisert bruker innimellom.
En slik tilnærming kan oppleves som en fornuftig balanse mellom behovet for
sletting og autorisert kontroll. Dersom dette er en ønskelig tilnærming vil
dette tvinge fram nye endepunkter i tjenestegrensesnittet. Disse vil kunne
utvikles under admin pakken.
Sletting kan også implementeres med en soft-delete tilnærming der innhold
ikke blir slettet men blir merket som slettet. Innholdet finnes ikke når det gjelder
søk og uttrekk, men kan hentes fram fra databasen ved behov. Soft-delete
løser ikke problemet der noe må fjernes fra arkivet pga feks nasjonalsikkerhet
men løser problemet der man oppretter noe man ikke skulle opprettet.
Begrenset sletting
Begrenset sletting er en tilnærming der innhold kan slettes inntil et bestemt
status angir at sletting ikke er mulig. Dette kan være basert på en
tidsavgrensning eller status verdier. I dag legger Noark opp til begrenset
sletting på dokumentinnhold ved at det er mulig å slette dokumenter fram til
dokumentet er arkivert. Etter dette skal det ikke være mulig å slette
dokumentet.
En annen tilnærming til sletting kan være basert på en tidsbegrensing. En
arkivenhet kan da slettes fram til et bestemt tidspunkt. Dette er ofte brukt
i kasseløsninger i butikker der det er mulig å gjøre endringer på en transaskjon
for et bestemt tidsinterval etter kjøpet er ferdig.
Sletting i Tjenestegrensesnittet
Tjenestegrensesnittet sier ikke så mye om sletting. Når det gjelder arkivenheter
står det:
Klienten sender en DELETE forespørsel på aktuell ressurs(url). Alle
ressurslenker med rel="self" kan potensielt slettes om bruker har nødvendige
rettigheter. Respons gir statuskode 204 om ressursen er korrekt slettet.
Arkivenheter kan slettes av en bruker dersom de er autorisert til å gjøre det.
Det er kanskje lurt å ta en diskusjon om tjenestegrensesnittet skal ta stilling
til hvorvidt en implementasjon bruker CASCADE DELETE i databasen? Altså hvis en
bruker sletter en arkivdel så vil alle barn slettes automatisk. Dvs klasser,
mapper, registreringer, dokumentbeskrivelser, dokumentobjekter og all assosiert
sekundær metadata feks korrespondanseparter.
Nåværende versjon av tjenestegrensesnittet sier ikke eksplisitt at en fil
tilknyttet et dokumentobjekt ikke kan slettes. Indirekte bør det forstås
at det ikke er mulig å slette en fil uten å slette dokumentobjektet. I
tjenestegrensesnittet står det:
Det er ikke mulig å overskrive filen tilhørende en eksisterende
dokumentobjekt-entitet med en POST eller en PUT-forespørsel. Hvis en fil må
erstattes etter fullført opplasting så skal dokumentobjekt-entiteten slettes
og en ny POST/PUT utføres mot href til
rel=https://rel.arkivverket.no/noark5/v5/api/arkivstruktur/fil/.
Det er verdt å merke at det er mulig å opprette et dokumentobjekt uten en
tilknyttet fil, men ikke mulig å slette en fil tilknyttet et dokumentobjekt.
Det er mulig at denne beskrivelsen må styrkes. Dette kan gjøres samtidig som
det kommer en bedre beskrivelse av kassasjon.
Man kan stille spørsmål om det er ønskelig at tjenestegrensesnittet skal ha
følgende forståelse.
Dersom en implementasjon bruker CASCADE DELETE og en autorisert bruker sletter
en arkivdel så betyr det at alle underliggende arkivenheter og dokumenter også
slettes. En slik DELETE forespørsel er ikke å anse som en kassasjon.
Sletting i Noark
Det er vanskelig å forstå sletting i Noark. XSD-skjemaene
viser at sletting er noe som kobles til enten en arkivdel eller en
dokumentbeskrivelse. Kapittel 7 i tjenestegrensesnittet viser det samme. En
sletting inneholder følgende metadata:
slettingstype
slettetDato
slettetAv
Forholdet mellom arkivdel og sletting er 1:1 så en sletting
her betyr at hele arkivdelen er slettet. Det samme gjelder forholdet
mellom dokumentbeskrivelse og sletting. Slettingstype har følgende
obligatoriske verdier:
Sletting av produksjonsformat
Sletting av tidligere versjon
Sletting av variant med sladdet informasjon
Ut ifra metadata beskrivelsene er sletting noe som kun er tenkt brukt på dokumenter.
Dokumentet,
definerer hvilken attributter som det skal logges endringer på men det er ikke
definert at sletting av en arkivenhet skal logges. Det står litt i standarden
om dette, men på et overordnet nivå.
Dermed oppleves det som om det enten ikke forventes at brukere skal kunne
slette arkivenheter eller at det er opp til implementasjonen hvorvidt dette skal logges.
Ut ifra dette kan vi tolke det slik at sletting er definert i Noark standarden
som noe som utføres på dokumenter, mens i tjenestegrensesnittet gjelder
sletting både dokumenter og arkivenheter. Sletting av arkivenheter skal logges.
Kassasjon
Innhold i arkivkjernen skal kun slettes på en kontrollert måte av autoriserte
brukere. Kassasjon er en formell prosess der arkivmateriale fjernes fra
arkivkjernen og fjerningen blir registrert. Vanligvis vil det å utføre en
kassasjon kun slette dokumenter, mens arkivenhetene (arkivstruktur metadata)
blir fortsatt tilgjengelig i systemet. I Noark standarden står det følgende om
kassasjon:
Kassasjon av dokumenter betyr ikke at metadata skal slettes. Arkivforskriften
har et bevaringspåbud for ”journaldatabaser”. Det betyr altså at metadata
om kasserte dokumenter i utgangspunktet skal bevares, og avleveres til depot.
Det er uklart hvilken arkivenheter skal slettes ved en kassasjon. Hvis en fil
ikke kan slettes fra arkivkjernen uten at assosiert dokumentobjekt også slettes
så må dokumentobjektet slettes ved en kassasjon.
Det er verdt å merke at registreringer som utgjør rettighetsdokumentasjon kan
slettes fra arkivet uten at de blir kassert. Kassasjon i tjenestegrensesnittet
er definert i henhold til dokumenter, ikke arkivenheter.
Noark legger opp til kassasjon på et makronivå, dvs kassasjon settes på
arkivdel eller klasse og det arves nedover i arkivstrukturen. Implementasjonen
av en makronivå kassasjonstilnærming kan være utfordrende å implementere i et moderne
REST-API da en REST-API ofte har fokus på funksjonalitet tilknyttet individuelle ressurser
framfor funksjonalitet på tvers av ressurser. På en annen måte er det mulig å
si at et REST-API er mer opptatt av implementere funksjonalitet på et
mikronivå. Det kan oppleves som en slags spenning mellom et ønske om makronivå
funksjonalitet og realiteten av et mikronivå implementasjon.
Hvordan tolkes en DELETE forespørsel?
Når vi ser på de forskjellige tilnærmingene til sletting kan det være greit å se
nærmere på hvordan en DELETE forespørsel til arkivkjernen skal tolkes.
Hvordan skal en arkivkjerne håndtere en DELETE forespørsel på følgende arkivenhet:
Skal dette tolkes som om en bruker opprettet arkivdelen ved en feiltagelse og nå
ønsker å slette arkivenheten? Eller skal det tolkes at brukeren ønsker å
slette alt innholdet (arkivenheter og dokumenter) eller at en bruker ønsker
å kassere innholdet (dokumenter)? Det samme kan gjelde dersom en bruker ønsker å
slette/kassere all innhold under en klasse feks:
Som en CRUD-implemetasjon så må tjenestegrensesnittet tolkes slik at det er
arkivenheten som skal slettes (arkivenheten kan da ikke ha barn).
Det gjenstår fortsatt et spørsmål om hvordan kassasjon skal utføres i
tjenestegrensesnittet. Noark standarden krever bruken av en kassasjonsliste
og dette er noe som antageligvis kan defineres med en OData søk:
OData spørringen (om den er riktig beskrevet) vil returnene en liste av dokumenter
som kan kasseres fordi det er definert at de skal slettes før oppgitt tidspunkt.
Her er det nå to muligheter for å håndtere den praktiske kassasjonen. Enten kan
klienten gjenbruke innholdet i listen (self-url til alle dokumenter), eller så
kan klienten utføre en DELETE forespørsel med den opprinnelige OData spørringen.
En interessant bemerkning med OData spørringen over er at dette gir
arkivkjernen et hint at dette er snakk om kassasjon så tjenestegrensesnittet
kan definere at kassasjon skjer når OData spørringen inneholder en JOIN som
inkluderer arkivenheten kassasjon og forespørselen er en DELETE. Dersom kassasjon ikke er en
del av URLen er det ikke snakk om en kassasjon, men en sletting.
Den samme tilnærmingen, men for sletting, kan brukes for å slette et utvalg av
dokumenter tilknyttet en dokumentbeskrivelse. En klient kan bruke en
OData spørring for å slette alle produksjonsformat varianter av dokumenter
tilknyttet en dokumentbeskrivelse. Følgende eksempel viser hvordan dette er mulig
for en dokumentbeskrivelse med systemID 236e819a-8e01-4c01-8500-29919c5898aa:
[DELETE] /api/arkivstruktur/dokumentobjekt&$filter=dokumentbeskrivelse/systemID eq '236e819a-8e01-4c01-8500-29919c5898aa' and variantFormat eq 'Produksjonsformat'
Fordi det er her ikke noe referanse til kassasjon i OData spørringen, kan
arkivkjernen anta at dette er snakk om sletting og ikke kassasjon.
Forskjellen mellom sletting og utfoertKassasjon
Det er litt uklart hva forskjellen mellom sletting og utfoertKassasjon er. Det
er opplagt at utfoertKassasjon skal få en verdi etter at kassasjonen er utført,
men det kan tenkes at en arkivkjerne kan misforstå og bare sette verdi på sletting
etter kassasjonen er utført. Det kan tenkes at en arkivkjerne angir et verdi både til
utfoertKassasjon og sletting.
utfoertKassasjon vil få en verdi etter at OData kassasjonen er gjennomført.
Hvis vi tar eksempelet fra tidligere:
Dette skal resultere i at alle dokumentene som er i kassasjonslisten blir slettet.
Oppsumering
Kassasjon
For at arkivkjernen skal tolke DELETE forespørselen som en kassasjon må det
være tilknyttet til en kassasjon entitet som en JOIN. Kassasjon resulterer
i at alle dokumenter i kassasjonslisten slettes og assosiert dokumentobjekt
slettes. Dokumentbeskrivelse blir liggende i systemet og får en
utfoertKassasjon objekt assosiert med seg.
Dokumentbeskrivelse og utfoertKassasjon er i en 1:1 forhold, mens
Dokumentbeskrivelse og dokumentobjekt er i en 1:m forhold. Det er uklart
hvorvidt det kan oppstå to kassasjon prosesser på samme dokumentbeskrivelse
og hvorvidt dette skal registreres.
Sletting av arkivenheter
Å slette et dokumentobjekt tvinger fram en sletting av assosiert fil på
lagringsmedium.
Arkivenheter kan slettes av en bruker dersom de er autorisert til å gjøre det.
Skal tjenestegrensesnittet ta stilling hvorvidt en implementasjon bruker
CASCADE DELETE i databasen? Altså hvis en bruker sletter en arkivdel så vil
alle barn slettes automatisk. Dvs klasser, mapper, registreringer,
dokumentbeskrivelser, dokumentobjekter og all assosiert sekundær metadata feks
korrespondanseparter. I utgangspunktet er jeg usikker om tjenestegrensesnittet trenger
ikke ta stilling til det. Er det en konsekvens på utvikling av klienter?
Sletting av filer:
Tjenestegrensesnittet skiller mellom kassasjon og sletting av filer. Det
er uklart hvorfor kassasjon kan kobles til langt flere arkivenheter enn det
sletting kan. Beskrivelsen av sletting i kapittel 7 sier litt om hva som kan
slettes. Dette bør kanskje få en egen forklaring. Er det kun dokumentstatus som
bestemmer hvorvidt en fil kan slettes? Feks er det fortsatt mulig å slette filer
tilkoblet en sak om har saksstatus "avsluttet" dersom journalposten
ikke har
Uklarheter i tjenestegrensesnittet
Beskrivelsen av sletting / kassasjon
Flytt beskrivelse om sletting av arkivenheter med self-rel fra kapittel 7
til kapittel 6
Tydelig forklaring at en fil tilkoblet et dokumentobjekt ikke kan slettes
uavhengig av dokumentobjektet
Sletting av dokumentobjekt innebærer at filen slettes fra lagringsmedium.
Dersom det ikke er mulig å bekrefte at filen er slettet kan ikke
dokumentobjektet slettes.
Dersom en fil brukes av flere dokumentobjekter, skal ikke filen slettes før
det siste dokumentobjektet er slettet.
Tydelig forklaring på når sletting og utfoertKassasjon blir brukt
petterreinholdtsen
commented
4 years ago
Sletting i tjenestegrensesnittet
Sletting er en tematikk som kan oppfattes som vanskelig i arkiv. På den ene siden er det ofte en holdning at man aldri sletter noe, fordi så fort du åpner opp for sletting så kan muligheten misbrukes. På den andre siden kan det være et reelt behov å slette noe fra arkivet fordi det er kommet inn noe i arkivet som ikke skulle vært der. Det kan for eksempel være personopplysninger som skal slettes etter pålegg fra datatilsynet eller dokumentasjon som er gradert "STRENGT HEMMELIG" som ved en feil kom inn i arkivet og som må trekkes ut.
Sletting
Til en viss grad må en bruker ha kontroll over sitt eget materiale og må ha muligheten til oppdatere og slette i arkivet. Vi kan tenke at sletting er ofte en slags unntak, men muligheten må være tilstede for at arkivkjernen skal oppleves som brukervennlig. Det er en vanskelig balanse mellom sikkerhet og funksjonalitet, der funksjonalitet kommer ofte på bekostning av sikkerhet. Hvis en bruker opplever at det ikke er mulig å slette innhold vil de kanskje velge å arkivere så lite som mulig. Men det kommer et punkt der det er nødvendig å nekte sletting, for eksempel når saken er avsluttet eller dokumentet er arkivert.
Uten en fleksibel tilnærmingen i tjenestegrensesnittet kan det bli vanskelig å bygge fagsystemer på toppen av et Noark API. Det kan være fagområder som omhandler arkivdanning som ønsker en mindre rigid kontroll av innhold og dersom tjenestegrensesnittet skal øke omfang av bruk kan det være fornuftig å åpne for mer tillit til klient systemer.
Tilnærmingen tjenestegrensesnitt kan legge opp til kan være basert på samme som tilnærming Ronald Reagan hadde i forhold til nedrustningsavtalen med sovjetunionen. Den bygger på en "Trust but verify" tilnærming. En slik tilnærming vil gi brukere mer kontroll over eget innhold, men vil trenge en tydelig logging og sporing slik at det er enkelt å ha oversikt over hva som skjer, spesielt med sletting.
En måte å løse dette på er at brukere kan slette dokumenter og arkivenheter de har tilgang til, men i realiteten flyttes det over til en intern "papir-kurv". Denne papir-kurven kan slettes av en autorisert bruker innimellom. En slik tilnærming kan oppleves som en fornuftig balanse mellom behovet for sletting og autorisert kontroll. Dersom dette er en ønskelig tilnærming vil dette tvinge fram nye endepunkter i tjenestegrensesnittet. Disse vil kunne utvikles under admin pakken.
Sletting kan også implementeres med en soft-delete tilnærming der innhold ikke blir slettet men blir merket som slettet. Innholdet finnes ikke når det gjelder søk og uttrekk, men kan hentes fram fra databasen ved behov. Soft-delete løser ikke problemet der noe må fjernes fra arkivet pga feks nasjonalsikkerhet men løser problemet der man oppretter noe man ikke skulle opprettet.
Begrenset sletting
Begrenset sletting er en tilnærming der innhold kan slettes inntil et bestemt status angir at sletting ikke er mulig. Dette kan være basert på en tidsavgrensning eller status verdier. I dag legger Noark opp til begrenset sletting på dokumentinnhold ved at det er mulig å slette dokumenter fram til dokumentet er arkivert. Etter dette skal det ikke være mulig å slette dokumentet.
En annen tilnærming til sletting kan være basert på en tidsbegrensing. En arkivenhet kan da slettes fram til et bestemt tidspunkt. Dette er ofte brukt i kasseløsninger i butikker der det er mulig å gjøre endringer på en transaskjon for et bestemt tidsinterval etter kjøpet er ferdig.
Sletting i Tjenestegrensesnittet
Tjenestegrensesnittet sier ikke så mye om sletting. Når det gjelder arkivenheter står det:
Arkivenheter kan slettes av en bruker dersom de er autorisert til å gjøre det. Det er kanskje lurt å ta en diskusjon om tjenestegrensesnittet skal ta stilling til hvorvidt en implementasjon bruker CASCADE DELETE i databasen? Altså hvis en bruker sletter en arkivdel så vil alle barn slettes automatisk. Dvs klasser, mapper, registreringer, dokumentbeskrivelser, dokumentobjekter og all assosiert sekundær metadata feks korrespondanseparter.
Nåværende versjon av tjenestegrensesnittet sier ikke eksplisitt at en fil tilknyttet et dokumentobjekt ikke kan slettes. Indirekte bør det forstås at det ikke er mulig å slette en fil uten å slette dokumentobjektet. I tjenestegrensesnittet står det:
Det er verdt å merke at det er mulig å opprette et dokumentobjekt uten en tilknyttet fil, men ikke mulig å slette en fil tilknyttet et dokumentobjekt. Det er mulig at denne beskrivelsen må styrkes. Dette kan gjøres samtidig som det kommer en bedre beskrivelse av kassasjon.
Man kan stille spørsmål om det er ønskelig at tjenestegrensesnittet skal ha følgende forståelse.
Sletting i Noark
Det er vanskelig å forstå sletting i Noark. XSD-skjemaene viser at sletting er noe som kobles til enten en arkivdel eller en dokumentbeskrivelse. Kapittel 7 i tjenestegrensesnittet viser det samme. En sletting inneholder følgende metadata:
Forholdet mellom arkivdel og sletting er 1:1 så en sletting her betyr at hele arkivdelen er slettet. Det samme gjelder forholdet mellom dokumentbeskrivelse og sletting. Slettingstype har følgende obligatoriske verdier:
Ut ifra metadata beskrivelsene er sletting noe som kun er tenkt brukt på dokumenter. Dokumentet, definerer hvilken attributter som det skal logges endringer på men det er ikke definert at sletting av en arkivenhet skal logges. Det står litt i standarden om dette, men på et overordnet nivå.
Dermed oppleves det som om det enten ikke forventes at brukere skal kunne slette arkivenheter eller at det er opp til implementasjonen hvorvidt dette skal logges.
Ut ifra dette kan vi tolke det slik at sletting er definert i Noark standarden som noe som utføres på dokumenter, mens i tjenestegrensesnittet gjelder sletting både dokumenter og arkivenheter. Sletting av arkivenheter skal logges.
Kassasjon
Innhold i arkivkjernen skal kun slettes på en kontrollert måte av autoriserte brukere. Kassasjon er en formell prosess der arkivmateriale fjernes fra arkivkjernen og fjerningen blir registrert. Vanligvis vil det å utføre en kassasjon kun slette dokumenter, mens arkivenhetene (arkivstruktur metadata) blir fortsatt tilgjengelig i systemet. I Noark standarden står det følgende om kassasjon:
Det er uklart hvilken arkivenheter skal slettes ved en kassasjon. Hvis en fil ikke kan slettes fra arkivkjernen uten at assosiert dokumentobjekt også slettes så må dokumentobjektet slettes ved en kassasjon.
Det er verdt å merke at registreringer som utgjør rettighetsdokumentasjon kan slettes fra arkivet uten at de blir kassert. Kassasjon i tjenestegrensesnittet er definert i henhold til dokumenter, ikke arkivenheter.
Noark legger opp til kassasjon på et makronivå, dvs kassasjon settes på arkivdel eller klasse og det arves nedover i arkivstrukturen. Implementasjonen av en makronivå kassasjonstilnærming kan være utfordrende å implementere i et moderne REST-API da en REST-API ofte har fokus på funksjonalitet tilknyttet individuelle ressurser framfor funksjonalitet på tvers av ressurser. På en annen måte er det mulig å si at et REST-API er mer opptatt av implementere funksjonalitet på et mikronivå. Det kan oppleves som en slags spenning mellom et ønske om makronivå funksjonalitet og realiteten av et mikronivå implementasjon.
Hvordan tolkes en DELETE forespørsel?
Når vi ser på de forskjellige tilnærmingene til sletting kan det være greit å se nærmere på hvordan en DELETE forespørsel til arkivkjernen skal tolkes.
Hvordan skal en arkivkjerne håndtere en DELETE forespørsel på følgende arkivenhet:
Skal dette tolkes som om en bruker opprettet arkivdelen ved en feiltagelse og nå ønsker å slette arkivenheten? Eller skal det tolkes at brukeren ønsker å slette alt innholdet (arkivenheter og dokumenter) eller at en bruker ønsker å kassere innholdet (dokumenter)? Det samme kan gjelde dersom en bruker ønsker å slette/kassere all innhold under en klasse feks:
Som en CRUD-implemetasjon så må tjenestegrensesnittet tolkes slik at det er arkivenheten som skal slettes (arkivenheten kan da ikke ha barn).
Det gjenstår fortsatt et spørsmål om hvordan kassasjon skal utføres i tjenestegrensesnittet. Noark standarden krever bruken av en kassasjonsliste og dette er noe som antageligvis kan defineres med en OData søk:
[GET] /api/arkivstruktur/dokumentobjekt?$filter=dokumentbeskrivelse/journalpost/saksmappe/klasse/kassasjon/kassasjonsdato lt DateTime '2020-05-20T12:00:00'
OData spørringen (om den er riktig beskrevet) vil returnene en liste av dokumenter som kan kasseres fordi det er definert at de skal slettes før oppgitt tidspunkt. Her er det nå to muligheter for å håndtere den praktiske kassasjonen. Enten kan klienten gjenbruke innholdet i listen (self-url til alle dokumenter), eller så kan klienten utføre en DELETE forespørsel med den opprinnelige OData spørringen.
En interessant bemerkning med OData spørringen over er at dette gir arkivkjernen et hint at dette er snakk om kassasjon så tjenestegrensesnittet kan definere at kassasjon skjer når OData spørringen inneholder en JOIN som inkluderer arkivenheten kassasjon og forespørselen er en DELETE. Dersom kassasjon ikke er en del av URLen er det ikke snakk om en kassasjon, men en sletting.
Den samme tilnærmingen, men for sletting, kan brukes for å slette et utvalg av dokumenter tilknyttet en dokumentbeskrivelse. En klient kan bruke en OData spørring for å slette alle produksjonsformat varianter av dokumenter tilknyttet en dokumentbeskrivelse. Følgende eksempel viser hvordan dette er mulig for en dokumentbeskrivelse med systemID 236e819a-8e01-4c01-8500-29919c5898aa:
Fordi det er her ikke noe referanse til kassasjon i OData spørringen, kan arkivkjernen anta at dette er snakk om sletting og ikke kassasjon.
Forskjellen mellom sletting og utfoertKassasjon
Det er litt uklart hva forskjellen mellom sletting og utfoertKassasjon er. Det er opplagt at utfoertKassasjon skal få en verdi etter at kassasjonen er utført, men det kan tenkes at en arkivkjerne kan misforstå og bare sette verdi på sletting etter kassasjonen er utført. Det kan tenkes at en arkivkjerne angir et verdi både til utfoertKassasjon og sletting.
utfoertKassasjon vil få en verdi etter at OData kassasjonen er gjennomført. Hvis vi tar eksempelet fra tidligere:
Dette skal resultere i at alle dokumentene som er i kassasjonslisten blir slettet.
Oppsumering
Kassasjon
For at arkivkjernen skal tolke DELETE forespørselen som en kassasjon må det være tilknyttet til en kassasjon entitet som en JOIN. Kassasjon resulterer i at alle dokumenter i kassasjonslisten slettes og assosiert dokumentobjekt slettes. Dokumentbeskrivelse blir liggende i systemet og får en utfoertKassasjon objekt assosiert med seg.
Dokumentbeskrivelse og utfoertKassasjon er i en 1:1 forhold, mens Dokumentbeskrivelse og dokumentobjekt er i en 1:m forhold. Det er uklart hvorvidt det kan oppstå to kassasjon prosesser på samme dokumentbeskrivelse og hvorvidt dette skal registreres.
Sletting av arkivenheter
Å slette et dokumentobjekt tvinger fram en sletting av assosiert fil på lagringsmedium.
Arkivenheter kan slettes av en bruker dersom de er autorisert til å gjøre det. Skal tjenestegrensesnittet ta stilling hvorvidt en implementasjon bruker CASCADE DELETE i databasen? Altså hvis en bruker sletter en arkivdel så vil alle barn slettes automatisk. Dvs klasser, mapper, registreringer, dokumentbeskrivelser, dokumentobjekter og all assosiert sekundær metadata feks korrespondanseparter. I utgangspunktet er jeg usikker om tjenestegrensesnittet trenger ikke ta stilling til det. Er det en konsekvens på utvikling av klienter?
Sletting av filer:
Tjenestegrensesnittet skiller mellom kassasjon og sletting av filer. Det er uklart hvorfor kassasjon kan kobles til langt flere arkivenheter enn det sletting kan. Beskrivelsen av sletting i kapittel 7 sier litt om hva som kan slettes. Dette bør kanskje få en egen forklaring. Er det kun dokumentstatus som bestemmer hvorvidt en fil kan slettes? Feks er det fortsatt mulig å slette filer tilkoblet en sak om har saksstatus "avsluttet" dersom journalposten ikke har
Uklarheter i tjenestegrensesnittet