Als gebruiker wil ik dat verschillende versies van zaaktypes hetzelfde UUID houden

[joeribekker]

...zodat notificatie-abonnementen in stand blijven op zaaktype en het veel eenvoudiger is om zaaktypes te beheren.

Issue kwam van gemeente Den Haag maar ben zelf ook zwaar voorstander hiervan, zodat versies beschikbaar komen. Bijv. als: <uuid>/versies/1 en <zelfde uuid>/versies/2

Het oorspronkelijke issue, zoals opgevoerd bij Open Zaak: open-zaak/open-notificaties#144 betrof voornamelijk dat notificatie abonnementen gepinned zijn op een UUID. Een nieuwe versie van het zaaktype verliest dus ook zijn abonnementen omdat het UUID wijzigt.

Deze side-effects zijn wel goed getackled met de Objecttypen API volgens bovenstaand patroon.

[HenriKorver]

Lijkt me een flinke breaking change, of vergis ik me?

@johannesbattjes @MNIJ Hoe kijken jullie tegen dit voorstel aan?

[michielverhoef]

De voorgestelde oplossing vereist nog steeds dat:

1. De consumer exact weet welke versie van een zaaktype nodig is. => Bij een nieuwe versie van een zaaktype moet dit dus aangepast worden in de consumer.
2. Een zaaktype geindentificeerd wordt door een UUID in plaats van een human readable identificatie. Inregelen van een consumer is dan in mijn ogen nog steeds lastiger dan met bijvoorbeeld een zaaktypeidentificatie.

Hoewel niet perfect is dit probleem al opgelost met het historiemodel in versie 1.3.0 van de Catalogi API. Hiermee kan aan met de zaaktype_list operatie een versie van een zaaktype geldig op een bepaalde datum opgevraagd worden. De consumer hoeft dus niet te weten wanneer een versie geldig is geworden (begin-/eindgeldigheid) of om welke versie het gaat. Die vraag gewoon om zaaktype "aanvragen parkeervergunning" geldig op 31-12-2024. Het voordeel is dat alle benodigde informatie vaak al bekend is (datumGeldigheid is de aanmaakdatum van de zaak). Wanneer de zaak aangemaakt is kan eventueel een rechtstreekse url naar de gebruikte versie van het zaaktype (met UUID) opgenomen bij de zaak maar je kunt de versie ook nog steeds eenvoudig opvragen met de queryparameters zaaktypeidentificatie en datumGeldigheid.

Jammer genoeg is dit niet goed beschreven, dat was ooit het plan voor q1 van 2024 maar dat liep even anders.

Zo te horen is het probleem niet zozeer de Catalogi API, daar is het al opgelost, maar de Notificatie API. Wanneer die aangepast wordt om niet te kijken naar UUIDs maar naar Zaaktypeidentificaties is het hele probleem m.i. opgelost.

Edit: API ipv APOI

[johannesbattjes]

Allen,

Het is nogal schetsmatig dus we zouden er graag meer van weten.
Eerste reactie: op zich een valide en misschien wel mooiere oplossing dan ZTC 1.3.
Wel is het zo dat in ZTC 1.3 zoals Michiel Verhoef zegt al een aantal problemen is opgelost op basis van andere principes. Het heeft ons veel tijd deze breaking change door te voeren, en het lijkt ons niet goed nu meteen weer een dergelijke inspanning te leveren op de ZTC. We zijn dan zigzaggend op weg naar de perfecte ZTC - terwijl andere belangrijke ZGW-terreinen stil liggen (producten, gegevens van betrokkenen, verzoeken,..).

De aanleiding van dit issue is ons niet duidelijk. In de Notificatie api zelf komen zaaktypes niet voor dacht ik.
Wat doet Open Notificaties met zaaktypes, kun je dat toelichten @joeribekker ?
Wel in de autorisatie-api en daar zou gebruik maken van zaaktype-identificatie in plaats van (versie-)url het 'onderhoud' ook veel simpeler kunnen maken. Maar daar is deze verandering niet voor nodig.