het verplicht zijn van rol.betrokkeneIdentificatie.verblijfsadres.aoaIdentificatie veroorzaakt problemen

[sergei-maertens]

Bug

In de Rol resource kan je betrokkeneIdentificatie attributen meegeven. Eentje daarvan is het verlijfsadres, en dat is een adresseerbaar object aanduiding, die zelf ook weer een aantal attributen kent. Hierin zijn de volgende attributen verplicht: aoaIdentificatie, wplWoonplaatsNaam, gorOpenbareRuimteNaam, aoaHuisnummer.

In een formulierenoplossing worden adresgegevens uitgevraagd, dus al deze verplichte attributen kunnen gevuld worden, behalve aoaIdentificatie. Deze informatie wordt gebruikt om de initiator vast te leggen van de zaak die via het formulier gestart wordt.

Mij lijkt het onlogisch dat al deze attributen tegelijk verplicht zijn - als je een aoaIdentificatie hebt, dan kan je daaruit toch de overige attributen afleiden, want het is een referentie die in de BAG staat (of hoort te staan). En omgekeerd, als je openbare ruimte, woonplaatsnaam en huisnummer (+ eventuele letter/toevoeging) hebt, dan zou je op basis hiervan het adresseerbaarobject in de BAG moeten kunnen vinden, dus dan verwacht ik dat aoaIdentificatie geen verplicht veld is.

Mis ik iets in deze redenering, of is dit inderdaad iets wat over het hoofd gezien is in de API specificatie/referentie-implementaties?

Ik denk dat we voor nu dus genoodzaakt zijn om dummy data naar de achterliggende zaken API te sturen om door de validatie heen te komen.

Alternatieve oplossingen bedacht

• In het formulier deze identificatie uitvragen -> onacceptabele eis voor eindgebruikers
• Aanduiding opzoeken in de BAG op basis van adresgegevens -> vereist een BAG koppeling in de formuliersoftware en is technisch complex in te passen, je kan niet eenvoudig even een veld mappen

[sergei-maertens]

#2193 gaat ook over een aantal van deze velden

[HenriKorver]

Mis ik iets in deze redenering, of is dit inderdaad iets wat over het hoofd gezien is in de API specificatie/referentie-implementaties?

Nee, ik denk ook dat dit een bug is. Echter de work-around is vrij simpel zoals jezelf al zegt: "stuur dummy data mee". Bijvoorbeeld, als je beschikt over de aoaIdentificatie dan stuur je lege strings mee voor wplWoonplaatsNaam, gorOpenbareRuimteNaam en 0 voor aoaHuisnummer. En andersom (als je niet beschikt over de aoaIdentificatie maar wel over de andere verplichte velden) dan stuur je een lege string mee voor de aoaIdentificatie.

Zullen we in de volgende versie van de Zaken API alle attributen van verblijfplaats optioneel maken om dit probleem netjes op te lossen?

[sergei-maertens]

Een lege string voor de aoaIdentificatie is niet toegestaan, deze moet minimaal 1 karakter zijn. Dus die workaround passen we nu wel toe, maar het leidt tot datavervuiling

Alles optioneel maken is ook geen oplossing, want je hebt gewoon combinaties nodig om een verblijfsobject te identificeren. Dat kan dus zijn:

• Een identificatie
• Of een combinatie postcode, huisnummer, naam openbare ruimte

Dit lijkt erg op de zoekparameters van de BRP personen bevragen - hier is meer uitleg nodig omdat je het niet puur in OAS constructies kan bevatten

[HenriKorver]

Bij mij is de lege string wel toegestaan bij aoaIdentificatie :

[sergei-maertens]

Oh apart, dan moet ik even kijken waarom dat elders anders is, of dat dit ergens als bugfix doorgevoerd was in de standaard.

…

On Mon, Aug 19, 2024, 15:44 Henri Korver ***@***.***> wrote: Bij mij is de lege string wel toegestaan bij aoaIdentificatie : afbeelding.png (view on web) <https://github.com/user-attachments/assets/ae0e6be1-cdfb-4c75-b448-8ea6a4f6e58b> — Reply to this email directly, view it on GitHub <#2451 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ABKDJVRTE2UMREHHRB5ADYTZSHZFXAVCNFSM6AAAAABK6GABIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGYYTOMRRGE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[HenriKorver]

Alles optioneel maken is ook geen oplossing, want je hebt gewoon combinaties nodig om een verblijfsobject te identificeren.

Eens.

Dit lijkt erg op de zoekparameters van de BRP personen bevragen - hier is meer uitleg nodig omdat je het niet puur in OAS constructies kan bevatten

Eens. Je bedoelt deze zoekparameters van de BRP neem ik aan: https://brp-api.github.io/Haal-Centraal-BRP-bevragen/v2/redoc#tag/Personen

Oh apart, dan moet ik even kijken waarom dat elders anders is,

Heb je al gekeken? Want als mijn observatie klopt kunnen we (voorlopig) de lege string voor aoaIdentificatie als workaround gebruiken.

[sergei-maertens]

dank voor het uitzoeken Henri, het was een bug in Open Zaak die ondertussen opgelost is! Ik ga dit ook terugcommuniceren naar een andere API implementatie waar we tegen dit euvel aanlopen!

edit: even teruggekeken in de geschiedenis - na 1.2.0 is dit verholpen, tot en met 1.2.0 Zaken API was dit nog een issue.

[johannesbattjes]

@HenriKorver twee vragen hierbij

Is het niet wonderlijk dat huisnummer niet leeg mag zijn terwijl alle andere velden wel leeg mogen zijn? Dus als je taakapplicatie een aoaIdentifcatie heeft (het voorbeeld van Sergei), moet deze nog wel het huisnummer meesturen.

Is er ergens een lijstje van stringvelden waarbij een soortgelijke verandering heeft plaatsgevonden?

[HenriKorver]

Is het niet wonderlijk dat huisnummer niet leeg mag zijn terwijl alle andere velden wel leeg mogen zijn? Dus als je taakapplicatie een aoaIdentifcatie heeft (het voorbeeld van Sergei), moet deze nog wel het huisnummer meesturen

Huisnummer is een integer en heeft niet zoals de andere string-velden een lege waarde van zichzelf (namelijk lege string ""). Ook is huisnummer niet gedefinieerd als nullable, dus we zullen in de bovengenoemde workaround een dummy waarde moeten meegeven bijvoorbeeld 0 of een random ander getal. Dit random getal hoeft dus niet het huisnummer te zijn dat bij de aoaIdentifcatie hoort, want als je dat wilt werkt de work-around niet meer :-)

Is er ergens een lijstje van stringvelden waarbij een soortgelijke verandering heeft plaatsgevonden?

Begrijp de vraag niet, kun je iets concreter zijn?

[johannesbattjes]

Suggestie: misschien goed om aan de omschrijving van het veld huisnummer het volgende toe te voegen: "vul huisnummer 0 in als het huisnummer niet voorhanden is"?

Wij hadden in onze implementatie van ZRC 1.5 niet gezien dat de toegestane waardes veranderd waren van [1...x] characters in ZRC 1.2 naar <= x characters in ZRC 1.3.

We moeten dus checken of we dit op meer plaatsen over het hoofd hebben gezien. Dus vandaar mijn vraag: is er een lijstje van velden waar de toegestane stringwaardes zijn veranderd van [1...x] characters naar <= x characters?
In ZRC 1.3 of wellicht later.