September 2026 - nikita-noark

Notasjon for registrering og oppdatering av flere foreldre til samme dokumentbeskrivelse?
by Petter Reinholdtsen 08 Sep '26

08 Sep '26

Dagens N5 og N5TG dokumenterer at det er mulig for en dokumentbeskrivelse å ha flere oppføringer av registrering som foreldre. Jeg antar dette er tenkt brukt til å spare plass, der samme fil gjenbrukes i flere oppføringer. Men det er uklart for meg hvordan slikt skal registreres av klienter som bruker N5TG i dag. Det er ikke klart fra notasjonen i hverken kapittel 6 eller 7 hvordan slikt skal foregå, og Nikita har så vidt jeg kan se ingen implementasjon av dette. Noen som har ide om hvordan notasjonen bør se ut? I dag har registrering en _links-oppføring med relasjonsnøkkel https://rel.arkivverket.no/noark5/v5/api/arkivstruktur/dokumentbeskrivelse/ som går til et endepunkt som returnerer en liste med underliggende dokumentbeskrivelser, og dokumentbeskrivelser har en _links-oppføring med relasjonsnøkkel https://rel.arkivverket.no/noark5/v5/api/arkivstruktur/dokumentbeskrivelse/ som går til et endepunkt som returnerer en liste med overliggende registreringer (eller journalposter og arkivnotater). Jeg mistenker notasjonen for å gi en dokumentbeskrivelse flere foreldre bør operere på endepunktslistene til enten registrering eller dokumentbeskrivelse, men synes hverken relasjonsnøkler for ny-dokumentbeskrivelse eller ny-registering helt er egnet da operasjonen ligner med på en flytte-operasjon eller håndtering av kryssreferanser der en ekstra relasjon skal legges inn. Sludderboten min kom opp med følgende forslag for å legge til en ekstra foreldre: PATCH /api/arkivstruktur/dokumentbeskrivelse/{dd-systemId} Content-Type: application/merge-patch+json If-Match: <etag> { "_links": { "https://rel.arkivverket.no/noark5/v5/api/arkivstruktur/registrering/": [ { "href": "https://n5.example.com/api/arkivstruktur/registrering/uuid-A/dokumentbeskri…" }, { "href": "https://n5.example.com/api/arkivstruktur/registrering/uuid-B/dokumentbeskri…" } ] } } Jeg er ikke overbevist om at det er riktig tilnærming. Kanskje en POST til href pekt til en av https://rel.arkivverket.no/noark5/v5/api/arkivstruktur/registrering/ eller https://rel.arkivverket.no/noark5/v5/api/arkivstruktur/dokumentbeskrivelse/ med noe ala dette kan fungere: { "_links": { "https://rel.arkivverket.no/noark5/v5/api/arkivstruktur/registrering/": [ { "href": "https://n5.example.com/api/arkivstruktur/registrering/uuid-A" } ] } } Jeg mistenker jo noe ala <URL: https://gitlab.com/OsloMet-ABI/nikita-noark5-core/-/merge_requests/605 > bør brukes, men er usikker på konkrete detaljer. -- Vennlig hilsen Petter Reinholdtsen

1 0

PUT, PATCH og kaos
by Petter Reinholdtsen 07 Sep '26

07 Sep '26

Mens jeg har holdt på å fikse Nikita-implementasjonen til å bli mer robust og komplett, så har jeg observert at det finnes tre mekanismer implementert i Nikta for å oppdatere registrert arkivinformasjon. PUT --- Her forventes det at en skal hente først med GET, endre felt og verdier en ønsker å endre, fjerne _links (med mindre en ønsker flytte oppføringen) og så gjøre PUT mot samme endepunkt. Jeg tror alle endepunkter nå støtter PUT, men det er mangelfull håndtering av feltsletting og forsøk på endring av verdier som ikke kan endres. Så vidt jeg kan forstå vil forsøk på å endre skrivebeskyttede verdier i dag ignoreres og sletting av tekst/tall-felt ignoreres, mens sletting av metadata-felt fører til intern feil i Nikita. N5TG spesifiserer denne, og dette var opprinnelig metode i N5TG for oppdatering av informasjon via API-et. Her må API-mottaket sammenligne innsendt informasjon med informasjonen i arkivet for å finne ut om et felt skal oppdateres eller ikke. PATCH med JSON-instrukser (RFC 6902) ------------------------------------ Her gir en instrukser i JSON-format (add/move/etc) om hva en ønsker endre, som så gjennomføres av Nikita. Dette er ikke tilgjengelig for alle endepunkt, og så vidt jeg kan se har den ikke god kontroll med hvilke felt som er skrivebeskyttet og hvilke som kan oppdateres. Med bruken av PATCH er det kun informajson om felt som skal endres som sendes over, hvilket gjør det enklere for mottaker å vite intensjon. Mekanismen var en kandidat til å komme inn i N5TG, og ble implementert i Nikita for å teste ut dette, men ble til slutt valgt bort til fordel for PATCH med JSON merge-last (RFC 7396) ------------------------------------ Her gir en JSON-format med de feltene som skal erstattes, tilordner dem 'null' hvis de skal slettes, og nikita oppdaterer så aktuelle felt. Dette er tilgjengelig for alle endepunkt og har så vidt jeg kan se god kontroll over skrivbarhetsstatus og sletting av felt. Denne mekanismen er lagt til N5TG som et alternativ til N5TG til bruk av PUT. Også her er det enklere å forstå intensjon med en endringsforespørsel enn PUT. Anbefaling ---------- Jeg tenker det er opphav til kaos å ha flere ulike mekanismer for å oppdatere informasjon i arkivet, spesielt når det er ulike implementasjoner med potensielt litt forskjellig oppførsel. JEg tenker det også gjør livet vanskeligere for API-klienter som må forholde seg til flere mulige mekanikker og ikke nødvendigvis vet hvilken som bør brukes når. Jeg tenker derfor at oppdatinging ved bruk av PATCH med JSON-instrukser RFC 6902 og PUT bør droppes fra både Nikita og N5TG, slik at det kun er en mekanisme igjen og vi kan konsentere innsatsen om å gjøre denne så robust og korrekt som mulig. Jeg tenker videre at selv om N5TG fortsatt nevner PUT som en mulighet, så bør Nikita dokumentere at denne muligheten ikke eksisterer i Nikita og at en i stedet må bruke PATCH i tråd med RFC 7396 for alle endringer. Det kan ta litt tid å få PUT ut av N5TG, men jeg tror Nikita ikke bør vente på dette før en reduserer kodebase og angrepsflate ved å fjerne PUT-støtte. Hva tenker dere andre? -- Vennlig hilsen Petter Reinholdtsen

2 4

$ref, _links, PATCH og PUT
by Petter Reinholdtsen 06 Sep '26

06 Sep '26

N5TG beskriver at $ref og $id kan brukes til å legge til eller oppdatere relasjoner mellom entiteter i arkivet. Jeg har aldri klart å forstå hvordan dette skulle fungere. For flytting er det spesifisert hvordan PATCH med oppdaterte verdier for aktuelle relasjonsnøkler kan brukes, og disse har jeg både sikret at er implementert i Nikita og sjekket at fungerer som de skal. Jeg tror mekanismen som brukes for flytting med fordel også kan brukes til andre relasjonsoppdateringer. Jeg foreslår derfor at alle oppdateringer av relasjoner mellom entiteter, det være seg foreldre/barn-relasjonen som oppdateres med flytting, forrige-/neste-relasjoner, kryssreferanser, sekunderklassifikasjon, avskrivinger og ligende oppdateres med bruk av relasjonsnøkler i _links. Det betyr at i stedet for følgende hentet fra N5TG, som skal opprette en ny referanse mellom registrering og dokumentbeskrivelse: POST https://n5.example.com/api/arkivstruktur/registrering/cf8e1d0d-e94d-4d07-b5… (og her forstår jeg ikke om en av dem eller begge disse entitetene er forventet å eksistere i forkant av nykoblingen) Med PATCH derimot oppretter en ny kobling fra en aktuell dokumentbeskrivelse og til en eksisterende registrering ala dette: PATCH https://n5.example.com/api/arkivstruktur/dokumentbeskrivelse/1fa94a89-3550-… { "_links": { "https://rel.arkivverket.no/noark5/v5/api/arkivstruktur/registrering/": { "href": "https://n5.example.com/api/arkivstruktur/registrering/cf8e1d0d-e94d-4d07-b5…" } } } En kan tilsvarende bruke PUT hvis hele entitetsdatasettet repeteres og ny _links legges til, men som nevnt tidligere foreslår jeg å droppe PUT fullstendig for å gjøre API-et mindre tvetydlig. Jeg har fått laget et par endringsforslag som implementerer denne tilnærmingen i <URL: https://gitlab.com/OsloMet-ABI/nikita-noark5-core/-/merge_requests/605 > og <URL: https://gitlab.com/OsloMet-ABI/nikita-noark5-core/-/merge_requests/615 > for henholdvis forrige-/nestearkivdel og kryssreferanser, og holder på å oppdatere møteendringen til å bruke samme notasjon for forrige og neste moetemappe og -registrering. Jeg foreslår at vi går for denne tilnærmingen i Nikita og foreslår at N5TG endres tilsvarende. Da blir det en uniform mekanisme for å både vise frem og endre relasjoner mellom entiteter (_links), der en ser fra resultatet en får fra GET hvordan en må bruke PATCH for å endre en relasjon. Og mekanismen er den sammen uansett om relasjonen eksisterer fra før eller ikke. Hva tror dere? -- Vennlig hilsen Petter Reinholdtsen

1 0

Hva er utfordringen med arkivdeler og klassifikasjonssystemer?
by Petter Reinholdtsen 06 Sep '26

06 Sep '26

Jeg kom over denne utkoblede testen i kodebasen til Nikita: /** * Verifies behaviour when a Series that already has a * ClassificationSystem is patched with a different * ClassificationSystem. * * Design question (unresolved): Should nikita reject this * request with a 4xx because the Series already has a * ClassificationSystem (forcing the client to explicitly * disassociate first), or should it silently replace the existing * association? The current implementation adds the new * ClassificationSystem without removing the old one, which is * incorrect regardless of which policy is chosen. * * Before enabling this test, add {@code * SECOND_CLASSIFICATION_SYSTEM_SYSTEM_ID} to {@code * basic_structure.sql} as a second ClassificationSystem not yet * associated with {@code SERIES_SYSTEM_ID}. * * @throws Exception if the HTTP interaction fails */ @Disabled("Unresolved design: reject-if-exists vs replace; implementation broken either way") @Test @WithMockNikitaUser public void associateSeriesWithDifferentClassificationSystem_thenOk() throws Exception { String seriesUrl = SLASH + HREF_BASE_SERIES + SLASH + SERIES_SYSTEM_ID; String patchUrl = seriesUrl + SLASH + NEW_CLASSIFICATION_SYSTEM; String classificationSystemHref = getSelfHref(SLASH + HREF_BASE_CLASSIFICATION_SYSTEM + SLASH + SECOND_CLASSIFICATION_SYSTEM_SYSTEM_ID); String payload = String.format( "{\"%s\": {\"href\": \"%s\"}}", REL_FONDS_STRUCTURE_NEW_CLASSIFICATION_SYSTEM, classificationSystemHref); String etag = getETag(seriesUrl); mockMvc.perform(MockMvcRequestBuilders .patch(patchUrl) .header("If-Match", etag) .accept(NOARK5_V5_CONTENT_TYPE_JSON) .contentType(NOARK5_V5_CONTENT_TYPE_JSON) .content(payload)) .andExpect(status().isOk()) .andExpect(jsonPath("$." + SYSTEM_ID).exists()); } Merk, jeg mistenker testen bruker feil relasjonsnøkkel i PATCH-operasjonen og burde vært REL_CASE_HANDLING_SECONDARY_CLASSIFICATION eller lignende, men det er på siden av mitt spørsmål. Antagelsen i kommentaren på toppen ser ut til å være at en arkivdel kun kan ha et klassifikasjonssystem, og jeg klarer ikke finne en kilde til den antagelsen. Noen som vet hvor den kommer fra? Så vidt jeg kan se er følgende struktur fullt ut akseptabel i Noark 5: arkiv - arkivdel - klassifikasjonssystem 1 - klasse 1 - klassifikasjonssystem 2 - klasse 2 Dagens implementasjon i Nikita lar en både opprette klassifikasjonssystem to med POST til ny-klassifikasjonssystem under aktuell arkivdel, men også flytte et klassifikasjonssystem fra en arkivdel til en annen. Gjeldende beskrankninger har altså intet problem med to klassifikasjonssystem på samme nivå under samme arkivdel. Er det i strid med N5v5? Det er altså i dag mulig å gå fra denne strukturen: arkiv - arkivdel 1 - klassifikasjonssystem 1 - arkivdel 2 - klassifikasjonssystem 2 til denne strukuren ved en enkel PATCH av klassifikasjonssystem 2 med aktuell _links-peker satt til arkivdel 1: arkiv - arkivdel 1 - klassifikasjonssystem 1 - klassifikasjonssystem 2 - arkivdel 2 Jeg trodde dette var greit, men kommentaren i testen gjør meg usikker, og jeg klarer altså ikke finne forklaring ved å titte i N5v5. Eller er dette en fullstendig misforståelse, og handler det i stedet om hvordan sekundærklassifikasjon skal håndtes på mappe og registreringsnivå, og har intet med arkivdel (series) å gjøre? Svært forvirret over den testen. -- Vennlig hilsen Petter Reinholdtsen

2 2

Etag i Nikita, standard If-Match: og historisk ETag:
by Petter Reinholdtsen 06 Sep '26

06 Sep '26

Dagens Nikita støtter to måter å bruke etag på. Aktuelle endepunkter gir ut en etag-verdi med "ETag:"-hodefeltet i HTTP-responser, som så kan tas imot i forespørsler som skal oppdatere entiteter. Dette siste mottas enten med "If-Match:" eller med "ETag:", se getETag() i AbstractEntityWebService.java. I følge <URL: https://datatracker.ietf.org/doc/html/rfc7232 >, er det kun den første som er i tråd med standarden, og den andre må være noe historiske rester i Niktita. Er det noen grunn til å beholde støtte for det ikke-standardiserte hodefeltet? Hvis ikke, så foreslår jeg å fjerne støtten og oppdatere alle tester som sender inn ETAG. Jeg har oppdatert mange tester allerede, men det kan være noen igjen. Jeg foreslår altså følgende endring: diff --git a/src/main/java/app/service/noark5/AbstractEntityWebService.java b/src/main/java/app/service/noark5/AbstractEntityWebService.java index e634db5ae..9a558e343 100644 --- a/src/main/java/app/service/noark5/AbstractEntityWebService.java +++ b/src/main/java/app/service/noark5/AbstractEntityWebService.java @@ -93,9 +93,6 @@ public class AbstractEntityWebService { } HttpServletRequest request = ((ServletRequestAttributes) requestAttributes).getRequest(); String eTag = request.getHeader(IF_MATCH); - if (eTag == null) { - eTag = request.getHeader(ETAG); - } if (eTag == null) { throw new NikitaMalformedHeaderException(ERROR_MISSING_ETAG); } Hva tenker dere andre? -- Vennlig hilsen Petter Reinholdtsen

2 3

2026

2025

2024

nikita-noark September 2026