Als zaakbehandelaar wil ik het informatieobjecttype kunnen aanpassen

johannesbattjes commented 3 years ago

Enkelvoudiginformatieobject - informatieobjecttype ("documenttype") is een verplicht veld. Dat betekent dat zodra het informatieobject wordt aangemaakt dit type moet worden meegegeven. Het informatieobjecttype mag niet gewijzigd worden.

Dit geeft een probleem: Als een document automatisch wordt toegevoegd, bijvoorbeeld uit een webformulier, en de behandelaar constateert dat de toekenning van het informatieobjecttype niet klopt, dan kan hij/zij dit niet meer wijzigen. Als het documenttype door een iniatiefnemer wordt bepaald (bijvoorbeeld in het omgevingskloket van DSO) en de zaakbehandelaar constateert dat het informatieobjecttype niet klopt dan kan hij/zij dit niet meer wijzigen.

Voorstel: maak informatieobjecttype wijzigbaar

NolWitte commented 3 years ago

Het niet kunnen wijzigen van het documenttype is onwerkbaar. Het kunnen wijzigen van metadata van documenten is nodig om het digitale archief goed te kunnen bijhouden. Behoudens het unieke documentkenmerk zie ik eigenlijk geen metadata die je niét zou moeten kunnen wijzigen na initiële registratie.

michielverhoef commented 3 years ago

Dit gaat dus over de relatie Informatieobject is van informatieobjecttype, niet over het informatieobjecttype in de ZTC.

Op zich vind ik de userstory aannemelijk. Wel moet het gedrag van de API dan zo zijn dat wanneer het informtatieobjecttype aangepast wordt ook de overige attributen die door dit type bepaald worden overgenomen worden.

Bijvoorbeeld vertrouwelijkheidsaanduiding. Stel dat ik eerst een informatieobject aanmaak van een type met vertrouwelijkheid "openbaar" en dit wordt later gewijzigd naar een type met vertrouwelijkheid "vertrouwelijk" moet dat wel bijgewerkt worden. Anders zijn vertrouwelijke documenten ineens openbaar terwijl dat niet de bedoeling is.

Ook mag alleen maar een geldig informatieobjecttype gekozen worden.

@hdksi Zie jij nog dingen die ik over het hoofd zie?

Jinze82 commented 2 years ago

@michielverhoef @hdksi Ik wil graag informeren hoe het staat met de voortgang rond dit punt van Johannes. We ondervinden hiervan al in testfase de ongemakken van (eigenlijk niet te doen). Bij ingang van de omgevingswet wanneer iedereen in productie gaat moet dit eigenlijk opgelost zijn anders hebben we als organisaties een probleem. Het is namelijk niet reëel om er vanuit te gaan dat documenten altijd correct binnenkomen met het juist documenttype. Bij het OLO lukte dit tot het niveau van 70% zuiverheid, bij het DSO denk ik dat we dit percentage zeker niet gaan halen. Daarnaast moet corrigeren in mijn ogen ook altijd mogelijk zijn. Hebben graag een antwoord zodat we weten waar we aan toe zijn, hopen natuurlijk op een oplossing voor live gang.

robklomp commented 2 years ago

Ik zou heel voorzichtig zijn met dit soort business rules in API's. Het kunnen corrigeren van fouten is in de praktijk regelmatig nodig. En inderdaad kan dat betekenen dat gerelateerde gegevens mee aangepast moeten worden.

MNIJ commented 2 years ago

Dit gaat dus over de relatie Informatieobject is van informatieobjecttype, niet over het informatieobjecttype in de ZTC.

Op zich vind ik de userstory aannemelijk. Wel moet het gedrag van de API dan zo zijn dat wanneer het informtatieobjecttype aangepast wordt ook de overige attributen die door dit type bepaald worden overgenomen worden.

Bijvoorbeeld vertrouwelijkheidsaanduiding. Stel dat ik eerst een informatieobject aanmaak van een type met vertrouwelijkheid "openbaar" en dit wordt later gewijzigd naar een type met vertrouwelijkheid "vertrouwelijk" moet dat wel bijgewerkt worden. Anders zijn vertrouwelijke documenten ineens openbaar terwijl dat niet de bedoeling is.

Ook mag alleen maar een geldig informatieobjecttype gekozen worden.

@hdksi Zie jij nog dingen die ik over het hoofd zie?

Dit staat al lang open, maar is nog steeds actueel.

Wat betreft het overnemen van vertrouwelijkheid, dat hoeft volgens mij niet de verantwoordelijkheid van de DRC te zijn. Dit kan, afhankelijk van de use-case, de verantwoordelijkheid zijn van de client-applictie of zelfs van de eindgebruiker. Het lijkt me juist onwenselijk als de DRC "klakkeloos" de vertrouwelijkheid van het nieuw gekozen informatieobjecttype overneemt. Bij een hoger vetrouwelijkheidsniveau is dat misschien correct, maar bij een lager niveau mogelijk juist niet. Ook is het mogelijk dat er bij het specifieke document al bewust een ander niveau is gekozen dan geconfigureerd in het oorspronkelijke informatieobjecttype.

Dus als de DRC dat automatisch gaat doen, wordt de oplossing complexer terwijl het eindresultaat niet per se beter is. Ik kan me wel voorstellen dat client-applicaties een waarschuwing geven als de eindgebruiker een informatieobjecttype kiest met een ander vertrouwelijkheidsniveau. Maar dat is dan een implementatiekeuze in de client-applicatie.

Jinze82 commented 2 years ago

Misschien even aanvullend op het verhaal van MNIJ hoe dit nu dagelijks verloopt, zijn verhaal sluit daar het beste op aan. Wij zien de vertrouwelijkheid bij een informatieobjecttype als “start” vertrouwelijkheid bij creatie of registratie. Deze is in tegenstelling tot wat de ZTC-OW aangeeft altijd lager dan openbaar, dit doen we al 10 jaar ivm met privacy gaan we uit van bewust openbaar.

We starten met zelf te creëren documenten op “Vertrouwelijk” of “intern”, alleen intern zichtbaar. Te ontvangen documenten starten met “Beperkt openbaar”, zodat zaak betrokken en aanvrager hun informatieobjecten zien op de persoonlijke site. Naarmate een document een andere “status” krijgt verandert de vertrouwelijkheid mee. Een begeleidende brief die adresgegevens bevat zal dan ook bij status “Definitief/Verzendbaar” nooit verder komen als “beperkt openbaar” en alleen zichtbaar op persoonlijke pagina’s. Het besluit dat geen persoonsgegevens bevat of geanonimiseerd is zal “openbaar” krijgen. Ontvangen stukken worden na redigeren omgezet naar eenduidig archiefwaardig formaat en op “Openbaar” worden gezet. Deze "Openbare" stukken worden gepubliceerd en worden zichtbaar in een digitaal bouwarchief dat voor iedereen toegankelijk is. Wijzigen van informatieobjecttype zou dan geen invloed moeten hebben.

hdksi commented 2 years ago

Voor wat betreft vertrouwelijkheid: in zowel de documentatie bij de standaard als in het RGBZ vind ik niet expliciet terug waarvoor Enkelvoudiginformatieobject.vertrouwelijkheidaanduiding nu precies bedoeld is. Wel constateer ik dat het vullen hiervan volgens de Documenten API niet verplicht is, terwijl die verplichting wel geldt het vullen van Informatieobejcttype.vertrouwelijkheidaanduiding in de Catalogi API.

Ik maak daaruit op dat Enkelvoudiginformatieobject.vertrouwelijkheidaanduiding bedoeld is als een soort 'override' voor gevallen waarin de vertrouwelijkheid van een specifiek document afwijkt van de standaardwaarde die geldt voor documenten van het bijbehorende type. Is die aanname correct?

Zo ja, dan lijkt het me allereerst goed dit in de documentatie te verduidelijken. Het zou het oplossen van deze user story in ieder geval vergemakkelijken: het eventueel aanpassen van Enkelvoudiginformatieobject.vertrouwelijkheidaanduiding naar aanleiding van het bijwerken van Enkelvoudiginformatieobject.informatieobjecttype is dan noch gewenst, noch nodig.

Verder zie ik geen bezwaren tegen het laten vervallen van de gedragsspecificatie die het wijzigen van informatieobjecttypen verhindert.

michielverhoef commented 1 year ago

Afgaande op de reactie van @hdksi hierboven:

informatieobjecttype wijzigbaar maken. Dit is een aanpassing van DRC-001
beschrijven in de gedragsregels hoe om te gaan met enkelvoudiginformatieobjecten.vertrouwlijkheidsaanduiding . Default geldt de waarde van het informatieobjecttype uit de Catalogi API. Afwijkingen kunnen worden vastgelegd in de Documenten API en hoeven dan niet aangepast te worden wanneer het zaaktype aangepast wordt.

MNIJ commented 1 year ago

Eens. Alleen bedoel je denk ik Informatieobjecttype waar je zaaktype schrijft.

michielverhoef commented 1 year ago

Ja, suf, dank je voor de aanvulling!

HenriKorver commented 1 year ago

informatieobjecttype wijzigbaar maken. Dit is een aanpassing van DRC-001

Om precies te zijn, de aanpassing betreft het weglaten van de laatste regel van DRC-001:

Als er geprobeerd wordt om het informatieobjecttype van een bestaand EnkelvoudigInformatieObject bij te werken (enkelvoudiginformatieobject_update, enkelvoudiginformatieobject_partial_update), dan MOET het DRC antwoorden met een HTTP 400 foutbericht.

hdksi commented 1 year ago

Vanuit het patroon zaak(type) bepaalt default vertrouwelijkheid informatieobject(type) nog even kritisch te kijken naar de verplichting een vertrouwelijkheidsaanduiding mee te geven bij creatie van een informatieobjecttype in de Catalogi API.

RemcovBeelen commented 1 year ago

Dit is ook een wens vanuit de gemeente Nieuwegein

Nunspeet commented 1 year ago

Dit is een issue die ik ook al bij de leverancier heb neergelegd. Het is absoluut niet handig dat wijzigingen/toevoegingen van informatieobjecttypen niet doorwerken in de inmiddeels aangemaakte zaken. De wens komt vaak voor vanuit een constatering in een bestaande zaak. De gewenste en doorgevoerde aanpassing werkt vervolgens niet door in desbetreffende zaken. Vervolgens moet er dan in de bestaande zaken een niet passend alter worden gekozen. Dit voor de eenduidigheid en werkbaarheid gewoonweg vervelend. Het kunnen aanpassen van informatieobjecttypen welke in reeds aangemaakte zaken doorwerken is zeer wenselijk. Het voorstel wordt door de gemeente Nunspeet van harte indersteund.

HenriKorver commented 1 year ago

Vanuit het patroon zaak(type) bepaalt default vertrouwelijkheid informatieobject(type) nog even kritisch te kijken naar de verplichting een vertrouwelijkheidsaanduiding mee te geven bij creatie van een informatieobjecttype in de Catalogi API.

@hdksi Regel drc-007 zegt hier het één en ander over.

afbeelding

Deze regel eist niet dat de vertrouwelijkheidsaanduiding die bij het InformatieObject wordt meegegeven gelijk of hoger moet zijn dan de waarde in het Informatieobjecttype. Lijkt mij wel wenselijk. Eens? Zo ja, dan zou ik bij het wijzigen van het Informatieobjecttype bij een bestaand Informatieobject ook een validatieregel toevoegen die checkt dat na de wijziging InformatieObject.InformatieObjectType.vertrouwelijkheidaanduiding niet een hogere vertrouwelijkheid heeft dan InformatieObject.vertrouwelijkheidaanduiding.

HenriKorver commented 1 year ago

informatieobjecttype wijzigbaar maken. Dit is een aanpassing van DRC-001

Om precies te zijn, de aanpassing betreft het weglaten van de laatste regel van DRC-001:

~Als er geprobeerd wordt om het informatieobjecttype van een bestaand EnkelvoudigInformatieObject bij te werken (enkelvoudiginformatieobject_update, enkelvoudiginformatieobject_partial_update), dan MOET het DRC antwoorden met een HTTP 400 foutbericht.~

Ook zal DCR-001 verder worden aangepast zodat ook bij het wijzigen van het type van een bestaand informatieobject er wordt gevalideerd of het nieuwe type bestaat c.q. geldig is.

HenriKorver commented 1 year ago

Deze regel eist niet dat de vertrouwelijkheidsaanduiding die bij het InformatieObject wordt meegegeven gelijk of hoger moet zijn dan de waarde in het Informatieobjecttype. Lijkt mij wel wenselijk. Eens? Zo ja, dan zou ik bij het wijzigen van het Informatieobjecttype bij een bestaand Informatieobject ook een validatieregel toevoegen die checkt dat na de wijziging InformatieObject.InformatieObjectType.vertrouwelijkheidaanduiding niet een hogere vertrouwelijkheid heeft dan InformatieObject.vertrouwelijkheidaanduiding.

Bij nader inzien zou ik voor nu toch maar geen extra validatieregel willen toevoegen, ook indien mogelijk wenselijk, omdat de aanpassing niet backwards compatible is.

HenriKorver commented 1 year ago

Bij deze het voorstel voor de aanpassing van DRC-001 in de vorm van een pull request: #2203.

HenriKorver commented 1 year ago

@johannesbattjes Is de voorgestelde oplossing naar wens (zie pull request: https://github.com/VNG-Realisatie/gemma-zaken/pull/2203)?

michielverhoef commented 1 year ago

@MNIJ @Jinze82 @johannesbattjes @NolWitte is dit voorstel #2203 voldoende om dit issue op te lossen?

michielverhoef commented 1 year ago

@MatthijsBekendam zoals besproken inbouwen in de referentie implementatie

michielverhoef commented 1 year ago

Verwerkt in PR https://github.com/VNG-Realisatie/documenten-api/pull/201

johannesbattjes commented 1 year ago

Hoi @michielverhoef ik snap niet wat ik moet lezen in #2033 - dat is een pull request en ik weet niet hoe dat werkt. Het gaat toch om de aanpassing van een business rule? De aanpassing van Henri lijkt me goed: "Om precies te zijn, de aanpassing betreft het weglaten van de laatste regel van DRC-001: Als er geprobeerd wordt om het informatieobjecttype van een bestaand EnkelvoudigInformatieObject bij te werken (enkelvoudiginformatieobject_update, enkelvoudiginformatieobject_partial_update), dan MOET het DRC antwoorden met een HTTP 400 foutbericht. Ook zal DCR-001 verder worden aangepast zodat ook bij het wijzigen van het type van een bestaand informatieobject er wordt gevalideerd of het nieuwe type bestaat c.q. geldig is."

HenriKorver commented 1 year ago

@johannesbattjes Het gaat om pull request #2203 en niet om #2033 waarnaar jij verwijst. Als het goed is, zijn de aanpassingen die jij noemt opgenomen in de eerst genoemde pull request (#2203).

johannesbattjes commented 1 year ago

Hoi Henri, dank voor de correctie maar mijn punt was dat ik niet wist wat ik moet doen met een pull request (dacht dat dat iets voor developers is) en ik zag niets inhoudelijks op genoemde pagina. Maar nu in tweede instantie zie ik dat je kunt zien bij "files changed" wat de wijziging is. Ziet er goed uit. Weer wat geleerd, dank je.

michielverhoef commented 1 year ago

De Documenten API 1.3.0 is uitgerold: https://documenten-api.vng.cloud/api/v1/schema/

In de documentatie is DRC-001 aangepast volgens het voorstel van @HenriKorver : https://vng-realisatie.github.io/gemma-zaken/standaard/documenten/#drc-001

johannesbattjes commented 1 year ago

@michielverhoef @HenriKorver nog een opmerking: in DRC-010 staat dit

Bijwerken van documenten (drc-010) overgenomen uit de openapi.yaml Bij het werken wordt gevalideerd of:

Een correcte lock waarde aanwezig is (zie (drc-009) De status NIET definitief is Het informatieobjecttype niet gewijzigd wordt

Moet de laatste opmerking hier niet weg?

michielverhoef commented 1 year ago

Dank voor de oplettendheid @johannesbattjes . Ik heb het gelijk aangepast.

VNG-Realisatie / gemma-zaken

Als zaakbehandelaar wil ik het informatieobjecttype kunnen aanpassen #1777