Metadata van inkomende documenten kunnen door twee verschillende business rules niet worden aangepast (terwijl dat wel zou moeten kunnen)

[johannesbattjes]

Een inkomend document, bijvoorbeeld een bijlage uit een DSO-verzoek, kan geen status in bewerking of ter vaststelling krijgen. Dit volgt uit business rule DRC-005: "Wanneer InformatieObject.ontvangstdatum een waarde heeft, dan zijn de waarden in bewerking en ter vaststelling voor InformatieObject.status NIET TOEGESTAAN.". Hieruit volgt dat dit document een van de twee andere statussen moet krijgen (definitief of gearchiveerd). Hiervan valt gearchiveerd af, omdat een document bij binnenkomst niet direct gearchiveerd wordt. Het inkomende document met ontvangstdatum moet dus volgens drc-005 de status definitief krijgen.

Documenten met status definitief kunnen niet worden aangepast. Dit volgt uit de volgende regel in de API (bij de PUT methode): "Er wordt gevalideerd op .... status NIET definitief". Dit betekent dat (metadata van) een definitief document nooit aangepast kan worden. In combinatie met drc-005 betekent dit dat een inkomend document met ontvangstdatum nooit aangepast kan worden. Maar dit is wel wenselijk:

• metadata ingegeven door geautomatiseerd systeem, indiener of medewerker kan incorrect of onvolledig zijn en moet aangepast kunnen worden
• het document moet status gearchiveerd krijgen
• als de vertrouwelijkheid niet goed is ingesteld leidt dit tot een verkeerde zichtbaarheid van het document. Dit moet kunnen worden aangepast.

Daarnaast is het ook niet wenselijk business rules in de API-specificatie te "verstoppen". Ze zouden expliciet als drc-xxx moeten worden geformuleerd.

Voorstel: laat de regel "Er wordt gevalideerd op ..." in de API specificatie geheel vervallen.

[michielverhoef]

Ik zie hier twee onderwerpen:
1/ Hoe om te gaan met een ingestuurd document.
2/ Waar staat wat in de documentatie.

Over het eerste punt:
Alleen documenten die zelf aangemaakt worden kunnen een status in bewerking of ter vaststelling hebben. Documenten die ontvangen worden kunnen alleen maar definitief zijn. Immers, de verzender heeft het document aangemaakt en ingestuurd. Het is geen concept waar de ontvanger nog iets mee zou moeten doen.

Wanneer een ingediend document niet goed of voldoende is moet de verzender een nieuw document opsturen. Bijvoorbeeld een bouwtekening die aangepast moet worden. Dat is een nieuw document, ook weer met de status definitief.

De metadata van een definitief document moet wel aangepast kunnen worden. zie bovengenoemde voorbeelden. In de Zaken API kennen we de scope zaken.geforceerd-bijwerken. Iets dergelijks zouden we ook moeten hebben in de Documenten API. Dan is meteen duidelijk dat een document in "normale omstandigheden" niet bewerkt kan/zou moeten worden maar als het echt moet kan het wel. Deze werkwijze is analoog aan het toch kunnen bijwerken van reeds gesloten zaken.
Hiervoor heb ik issue #1859 aangemaakt.

Het tweede punt, de plek waar gedocumenteerd wordt, is volledig valide. Wanneer documentatie te versnipperd is moet je te veel zoeken. Dit gaat aangepast worden in de volgende versie. Voor de huidige versie zal ik de informatie uit de yaml ook opnemen in de pagina's met bedrijfsregels. Hiervoor heb ik #1858 aangemaakt.

[johannesbattjes]

Maar hoezo "geforceerd bijwerken". Er zijn toch heel veel "normale" scenario's waarin de metadata moet worden aangepast?

• status gaat van definitief naar gearchiveerd
• het automatisch toegekende documenttype matcht niet met de inhoud
• de ontvangstdatum klopt niet
• de omschriving matcht niet met de inhoud

[michielverhoef]

het automatisch toegekende documenttype matcht niet met de inhoud

Dit is een probleem want informatieobjecttype mag niet gewijzigd worden: https://vng-realisatie.github.io/gemma-zaken/standaard/documenten/index#drc-010
(NB. dit stond eerder in de openapi.yaml en is verhuisd naar de specificatie van gedrag. #1858 )

Maar het kan inderdaad dat er metagegevens aangepast moeten worden omdat deze niet goed opgeslagen zijn.

[Jinze82]

@michielverhoef Zie dat dit item is opgenomen, om een beeld te krijgen waar we aan toe zijn. Voor wanneer wordt dit in het standaard aangepast?

[michielverhoef]

Als ik het zo goed begrijp mag volgens het RGBZ 2 een informatieobject alleen niet gewijzigd worden wanneer deze de status "gearchiveerd" heeft.

Zie ook https://www.gemmaonline.nl/index.php/Rgbz_2.0/doc/attribuutsoort/informatieobject.status
Wijziging van de Status in ‘gearchiveerd’ impliceert dat het informatieobject een duurzaam niet wijzigbaar Formaat dient te hebben. Aangezien er geen standaard bekend is voor dergelijke bestandsformaten, is dit niet in de ‘Regels attribuutsoort’ opgenomen maar zou hiervan wel sprake moeten zijn.

Zelfs de inhoud van een Informatieobject met status definitief zou dus nog aangepast moeten kunnen worden, bijvoorbeeld wanneer er een typefout in voor blijkt te komen. Dit zou dan wel onder bepaalde voorwaarden moeten. Zoiets als geforceerd_bijwerken oid.

[michielverhoef]

opgelost met PR 156

[johannesbattjes]

@michielverhoef hoe is dit opgelost? Ik zie bij 1.2 nog steeds staan:
Er wordt gevalideerd op..... status NIET definitief
DRC-005 is ook niet aangepast.

[ArjanKloosterboer]

Hiervan valt gearchiveerd af, omdat een document bij binnenkomst niet direct gearchiveerd wordt.

Documenten die ontvangen worden kunnen alleen maar definitief zijn. Immers, de verzender heeft het document aangemaakt en ingestuurd. Het is geen concept waar de ontvanger nog iets mee zou moeten doen.

Een document dat ontvangen wordt, dient direct gearchiveerd te worden. Daarmee is gewaarborgd dat het duurzaam en onveranderd bewaard wordt. Dat betreft primair de inhoud en vorm van het document. Bepaalde metagegevens kunnen alsnog ingevuld of gewijzigd worden, mits dat geen inbreuk maakt op de aard van de inhoud van het document.

[michielverhoef]

@michielverhoef documentatie nalopen

[johannesbattjes]

@michielverhoef wat is nu de oplossing?

[johannesbattjes]

Beste @michielverhoef
Ik zie hier nog tegenstrijdigheden. Het lijkt dat je de scope Geforceerd bijwerken als oplossing aandraagt.
Voor zover ik kan vinden is dat een autorisatie, en autorisaties gelden voor een (hele) applicatie. Dus bij voorbeeld heel Rx.Mission mag geforceerd bijwerken. En de betekenis van deze scope is: "changes meta data of all documents including "definitief" ones". Als dit de oplossing is, is de consequentie dat Rx.Mission deze scope krijgt en dus altijd alle meta data mag wijzigen. Dat zou dan als consequentie hebben dat alle regels met betrekking tot het wijzigen van meta data (zoals DRC 005) vervallen zodra een applicatie deze scope heeft. Maar dan lijkt het redelijk zinloos deze business regels op te stellen.
Mogelijk zie ik wat over het hoofd? Zo ja - op welke pagina kan ik dat dan vinden?

Zo nee dan lijkt het mij veel beter om als oplossing voor dit issue een logisch geheel van samenhangende business rules op te stellen, en niet een uitstapje te maken naar autorisatie.

[michielverhoef]

Een document dat ontvangen wordt, dient direct gearchiveerd te worden. Daarmee is gewaarborgd dat het duurzaam en onveranderd bewaard wordt. Dat betreft primair de inhoud en vorm van het document. Bepaalde metagegevens kunnen alsnog ingevuld of gewijzigd worden, mits dat geen inbreuk maakt op de aard van de inhoud van het document.

Als ik deze reactie van @ArjanKloosterboer goed begrijp mag de inhoud van het document ("de blob") niet gewijzigd worden maar zou het wel mogelijk moeten zijn om bepaalde metadata te wijzigen. Dat lijkt me een prima oplossing.

Dus de PUT/PATCH operaties kunnen toegestaan worden op de metadata van het enkelvoudiginformatieobject met status definitief. De inhoud mag niet meer aangepast worden.

Is dit werkbaar @johannesbattjes?

Om nog op je vraag in te gaan: De scope geforceerd bijwerken zou een workaround zijn om met de huidige versie van de Documenten API een enkelvoudiginformatieobject met status definitief toch te kunnen bewerken. Dat verdient geen schoonheidsprijs, dat geef ik toe. Ik zie liever een verbetering in de bedrijfsregels zoals hierboven.

[Jinze82]

Deze oplossing gaat de verkeerde kant op in mijn ogen omdat de reactie van Arjan het uitgangspunt is. Ik ben het dan ook niet helemaal eens met dit uitgangspunt, volgens mij moet je zelfs toevoegingen kunnen doen op de inhoud als een handtekening. In gecertificeerde ondertekeningstool of accordeer tools die wij gebruiken (Validsign / DigEplan) gaan juist ervan uit dat je op een pdf/a de toevoeging doet (idd bestands inhoudelijk qua tekst onwijzigbaar en archief waardig), dus de definitieve versie zoals jullie die noemen. Dit tast de originele inhoud niet aan maar geeft wel een andere status aan die zelfde inhoud, die is vastgesteld. De meeste mensen geloven het niet maar bij de gemeente doen we ook nog wat, de documentflow eindigt daarom ook niet bij de klant in mijn ogen. Daarnaast als meerdere moeten ondertekenen is een bewerkbaar formaat ter vaststelling zelfs zeer onwenselijk, wat nu wel wordt toegelaten. Met het huidige uitgangspunt kan het ZGW standaard nooit samenwerken met gecertificeerde vaststelling tools, dit lijkt mij niet de bedoeling. Kunnen jullie nog eens dit uitgangspunt breder tegen het licht houden? Komt nu over dat alleen geredeneerd wordt vanuit archiefwet, dat is niet de enige wet. Sluit me daarom aan bij Johannes om de bedrijfsregels logischer te maken.

[michielverhoef]

@Jinze82 Het is denk ik een interpretatie van wat inhoud is. Wat ik bedoelde met wijzigen van inhoud is de tekst van het document aanpassen. Of er een afbeelding of grafiek aan toevoegen. Dat is denk ik wat jij omschrijft als "qua tekst onwijzigbaar en archiefwaardig."

Voor mij is een ondertekening dan ook geen inhoud maar ook een vorm van metadata. De tekst is immers niet veranderd.

Alleen begrijp ik uit bovenstaande dat een digitale-ondertekeningstool iets in de body van het document toevoegt en dat zou niet kunnen wanneer de body niet meer aangepast mag worden. De vraag is dus hoe dat zo te omschrijven dat het werkbaar blijft (wordt) en toch correct.

[johannesbattjes]

Deze is opgelost via issue #2241 in DRC 1.4