Open sergei-maertens opened 1 month ago
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?
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:
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
Bij mij is de lege string wel toegestaan bij aoaIdentificatie :
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 https://github.com/VNG-Realisatie/gemma-zaken/issues/2451#issuecomment-2296617211, or unsubscribe https://github.com/notifications/unsubscribe-auth/ABKDJVRTE2UMREHHRB5ADYTZSHZFXAVCNFSM6AAAAABK6GABIWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDEOJWGYYTOMRRGE . You are receiving this because you authored the thread.Message ID: @.***>
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.
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.
@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?
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?
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.
Bug
In de
Rol
resource kan jebetrokkeneIdentificatie
attributen meegeven. Eentje daarvan is hetverlijfsadres
, 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 dataoaIdentificatie
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