Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
sergei-maertens opened this issue Jul 16, 2024 · 10 comments
Labels
2024 bug Iets werkt niet zoals bedoeld known issue

Comments

@sergei-maertens
Copy link
Collaborator

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 sergei-maertens added the bug Iets werkt niet zoals bedoeld label Jul 16, 2024
@sergei-maertens
Copy link
Collaborator Author

#2193 gaat ook over een aantal van deze velden

@HenriKorver
Copy link
Collaborator

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
Copy link
Collaborator Author

sergei-maertens commented Aug 19, 2024

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
Copy link
Collaborator

Bij mij is de lege string wel toegestaan bij aoaIdentificatie :

afbeelding

@sergei-maertens
Copy link
Collaborator Author

sergei-maertens commented Aug 19, 2024 via email

@HenriKorver
Copy link
Collaborator

HenriKorver commented Aug 22, 2024

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
Copy link
Collaborator Author

sergei-maertens commented Sep 2, 2024

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
Copy link

@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
Copy link
Collaborator

HenriKorver commented Sep 2, 2024

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
Copy link

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.

@HenriKorver HenriKorver reopened this Sep 3, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
2024 bug Iets werkt niet zoals bedoeld known issue
Development

No branches or pull requests

3 participants