Archiveren
Auteur: Joeri Bekker | Status: In voorbereiding
TODO: REST KOPIEREN VAN NOTION
Zaak-gerelateerde dingen
Een ZAAK kan aan allerlei "dingen" gerelateerd worden, om allerlei redenen. De term "ding" wordt hier gebruikt om niet de indruk te wekken dat het enkel om OBJECTEN in de Objecten API gaat. Ter illustratie:
Er komt een VERZOEK binnen om een BOOM te verwijderen omdat deze is omgevallen op een PAND. Er wordt ook een foto toegevoegd als ENKELVOUDIG INFORMATIEOBJECT. Het VERZOEK, BOOM, PAND worden aan een ZAAK gekoppeld die is gecreëerd n.a.v. het VERZOEK. Later is over deze ZAAK nog contact geweest met de initiator en vastgelegd in een KLANTCONTACT. Er zijn daarnaast nog wat ZAAKDETAILS vastgelegd die niet binnen de ZAAK konden worden vastgelegd.
Schematische weergave:
ZAAK (in Zaken API)
ZAAK-INFORMATIEOBJECT
ENKELVOUDIG INFORMATIEOBJECT (in Documenten API)
ZAAKOBJECT (overige)
VERZOEK (in Verzoeken API * in wording)
ZAAKOBJECT (overige)
BOOM (in Objecten API)
ZAAKOBJECT (standaard)
PAND (in de BAG)
ZAAKOBJECT (overige)
ZAAKDETAILS (in Objecten API)
KLANTCONTACT (in Klantinteracties API)
ONDERWERPOBJECT
ZAAK (in Zaken API)
Wat moet er gebeuren?
Wat moet er verwijderd worden als de ZAAK vernietigd wordt?
Het ENKELVOUDIG INFORMATIEOBJECT (de foto) moet vernietigd worden.
Het VERZOEK was de reden om de ZAAK te starten en moet vernietigd worden.
De BOOM zit in de Objecten API. Als de BOOM onderdeel is van een soort register van BOMEN, dan mag deze niet vernietigd worden. De BOOM bestaat immers nog. Als de BOOM enkel is aangemaakt t.b.v. deze ZAAK dan moet deze wel vernietigd worden.
Het PAND zit in een (andere) basisregistratie en zal niet vernietigd moeten worden. Het pand bestaat immers nog.
De ZAAKDETAILS horen bij de ZAAK en moeten vernietigd worden.
Analyse
Hoe stellen we programmatisch vast dat een "ding" gekoppeld een ZAAK vernietigd moet worden of niet? Voor een INFORMATIEOBJECT bestaat al een werkend patroon, en gaat uit van "altijd mee-archiveren tenzij elders gebruikt". We laten verder het KLANTCONTACT even buiten scope door de omgekeerde relatie.
Blijft over, ZAAKOBJECTEN. Er zijn 2 soorten ZAAKOBJECTEN:
ZAAKOBJECT vanuit de vast lijst met (RSGB) objecttypen, zoals een PAND.
ZAAKOBJECT met een overig objecttype, typisch een verwijzing naar een object in de Objecten API.
Oplossingsrichtingen ZAAKOBJECTEN
Er zijn 5 mogelijke oplossingsrichtingen:
(applicatie in de lead) Op ZAAKOBJECT wordt een nieuw attribuut geïntroduceerd:
meeArchiveren (boolean). Dit attribuut geeft aan of gepoogd moet worden om het gekoppelde ding te vernietigen zodat de ZAAK vernietigd wordt.(applicatie wordt geholpen) Hetzelfde als (1) maar daarnaast leggen we op ZAAKTYPE ook vast welke gekoppelde ZAAKOBJECT-OBJECTTYPEN bij een ZAAKTYPE kunnen horen en alvast een default waarde voor
meeArchiverenopgeven. Je kan dit op ZAAK niveau nog steeds overrulen.(automagisch) Alle ZAAKOBJECTEN met een RSGB objecttype, worden standaard niet gepoogd te vernietigen. ZAAKOBJECTEN met een overig objecttype worden wel gepoogd te vernietigen. Dit zou bij de BOOM fout kunnen gaan, tenzij we afspraken maken dat die niet gekoppeld had moeten worden maar of dat correct is...
(opgenomen zonder checks) In de Zaken API wordt een resource toegevoegd voor "dingen" die mee gearchiveerd moeten worden. Dit kan een eenvoudig attribuut zijn die een JSON-object toestaat. We verliezen hiermee echter de voordelen van een contract: Je weet niet van te voren wat er in zo'n ZAAK allemaal aan JSON-objecten zit. Herbruikbaarheid is ook laag.
(opgenomen met checks) Hetzelfde als (4) maar dan gevalideerd tegen een JSON schema, wat is opgenomen in het ZAAKTYPE als ZAAKOBJECTTYPE of iets dergelijks. In principe wordt de Objecten/Objecttypen API hiermee een soort onderdeel van de ZGW APIs.
Oplossingsrichtingen omgekeerde relaties
Relatie veranderen zodat deze loopt vanuit de ZAAK
Relatie spiegelen zoals bij INFORMATIEOBJECTEN
Separate afspraken maken over archiveren van KLANTCONTACTEN (en andere registraties die omgekeerde relaties leggen)
Last updated