Hei,
Nikita har i dag ingen forståelse for hvordan kassering skal gjøres i praksis. Jeg mener at tjenestegrensesnittet antyder en tilnærming basert på Noark, men det mangler en forståelse for implementasjonen. Likevel synes jeg din beskrivelse er veldig god, og jeg kan støtte den.
Tidligere har jeg forsøkt å initiere en diskusjon om hvordan sletting og kassasjon skal tolkes:
https://github.com/arkivverket/noark5-tjenestegrensesnitt-standard/issues/26...
Beskrivelsen over tar utgangspunkt i at hele kassasjonsprosessen utføres på serveren som en transaksjon, mens din tilnærming gjør det til en prosess styrt av klienten. Jeg mener at din tilnærming er en enklere løsning som gir bedre granularitet og kontroll i prosessen.
Jeg tror løsningen her må være å bruke en OData spørring med DELETE verb.
Jeg har ofte påpekt viktigheten av OAuth-claims, og jeg mener at en kassasjon kun bør utføres dersom klienten har en "kassasjon"-claim i sin samhandlingstoken.
Thomas
________________________________ Fra: Petter Reinholdtsen pere@hungry.com Sendt: fredag 29. november 2024 12:42 Til: nikita-noark@nuug.no nikita-noark@nuug.no Emne: Notater om kassasjon i Nikita
Jeg har tenkt litt i det siste på hvordan kassasjon bør fungere i Nikita, og har noen notater. En nyttig kilde er <URL: https://eur02.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwww.arkivv...https://www.arkivverket.no/for-arkiveiere/bevaring-og-kassasjon/om-bevaring-og-kassasjon-i-offentlig-forvaltning >, samt N5- og N5TG-spesifikasjonene. Jeg forsøker her å beskrive hvordan jeg forstår Kassasjon i relasjon til Nikita og N5TG.
Hvis jeg forstår det riktig, slå er Kassasjons-elementet ment å notere intensjon om kassering. Elementet er i dag del av Arkivdel, Klasse, Mappe, Registrering og Dokumentbeskrivelse, som alle kan ha en eller ingen kassasjonselementer. Elemtet ser i TG i dag slik ut:
class Kassasjonsvedtak <<codelist>> { +Bevares = B +Kasseres = K +Vurderes senere = G }
class Kassasjon <<dataType>> { +kassasjonsvedtak : Kassasjonsvedtak +kassasjonshjemmel : string [0..1] +bevaringstid : integer +kassasjonsdato : datetime }
En kan her notere om ting skal bevares, vurderes senere eller kasseres. Aktuell verdi for kassasjonsvedtak er her "K=kasseres". Når en ser på et klassifikajonssystem som fupperåd, så er det der lagt inn informasjon om bevaringstid. Antall år kan legges inn i Kassasjon.bevaringtid for hver klasse der slikt er definert. Dette lar arkivet ta vare på intensjon om kassering. Et kassasjonselement gjelder for alle underliggende instanser, slik at et element i Klasse vil gjelde for alle underklasser, mapper, registreringer, dokumentbeskrivelser og dokumentobjekter, med mindre de overstyres av kassasjonselementer i underliggende entiteter.
Selve kassasjonen kan enten skje automatisk, eller med manuelle rutiner der noen søker opp alle dokumentobjekter (med tilhørende dokumentbeskrivelser, registreringer, mapper) der aktuell dato (opprettetdato?) er mer enn bevaringstid antall år siden, eller der kassasjonsdato er passert. En kassasjon innebærer at en dokumentobjekt-instans slettes. Tilhørende fil slettes også hvis det var siste referanse til filen. N5-spesifikasjonen sier at det bør være mulig å angre kassasjon, slik at det bør være en mekanisme for tostegs sletting, der først referanser markeres for sletting, for så senere gjennomføre den fysiske slettingen. Øvrige instanser (dokumentbeskrivelse, registrering, mappe) kasseres aldri. I forbindelse med sletting (umiddelbart før eller etter), legges det inn en UtfoertKassasjon-entitet i dokumentobjektets foreldre-dokumentbeskrivelse. Disse kan i dag legges inn i Arkivdel og Dokumentbeskrivelse, og ser slik ut:
class UtfoertKassasjon <<dataType>> { +kassertDato : datetime [0..1] [1..1] +kassertAv : string [0..1] [1..1] +referanseKassertAv : SystemID [0..1] [1..1] }
Her noteres altså at det eksisterte et eller annet under dokumentbeskrivelse som er blitt slettet på kassertDato. I og med at det ikke kan noteres informasjon om hvilket dokumentobjekt som ble kassert, virker det nærliggende å anta at alle barn av en dokumentbeskrivelse kasseres samtidig. N5 gjør det klart at en ikke skal kunne kassere journalposter (aka registreringer) og saksmapper (aka mapper) som er notert å skape presedens. Jeg antar det betyr at en heller ikke kan kassere dokumentobjekter i slike mapper og registreringer.
Jeg mistenker det også bør opprettes en UtfoertKassasjon på arkivdelnivå når en arkivdel er avsluttet og en har utført kassasjon på alt under arkivdelen, for å notere at en ikke trenger tenke mer på det for alt materiale under denne.
Slik kassasjon kan da utføres med en API-klient som søker ut aktuelle dokumentobjekt-instanser. Jeg mistenker det er lurt å legge inn UtfoertKassasjon-elementer før sletting av dokumentobjekter, i tilfelle databasen faller ned i prosessen, for å sikre at en ikke mister kobling til en fil før det er notert at filen er kassert.
Stemmer denne beskrivelsen med deres forståelse av hvordan kassering skal gjøres med N5TG og Nikita?
-- Vennlig hilsen Petter Reinholdtsen _______________________________________________ nikita-noark mailing list -- nikita-noark@nuug.no To unsubscribe send an email to nikita-noark-leave@nuug.no