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

🐛 Date(time) formats as dictated by Open Zaak EIGENSCHAP (SPECIFICATIE) with formaat: Datum or Datumtijd are not supported by zgw_consumers #72

Open
damm89 opened this issue Oct 4, 2023 · 1 comment
Labels
bug Something isn't working good first issue Good for newcomers

Comments

@damm89
Copy link
Contributor

damm89 commented Oct 4, 2023

General information
Zgw_consumers version: 0.16.1 (but also relevant in latest version)

Describe the bug
Open Zaak dictates that a date value of an EIGENSCHAP with EIGENSCHAP SPECIFICATIE formaat: Datum should have as its length 8. Zgw_consumers uses default python packages that don't support the format DICTATED by Open Zaak. Both of which use/support python 3.9. (3.11 does support YYYYMMDD)
The lines to blame:

EIGENSCHAP_FORMATEN = {

To Reproduce
Steps to reproduce the behavior:
In Open Zaak:

  1. Create ZAAKTYPE
  2. Create EIGENSCHAP for ZAAKTYPE (1) with a EIGENSCHAP SPECIFICATIE that has formaat: Datum (i.e. length must be 8).
  3. Create ZAAK of ZAAKTYPE (1)
  4. Create ZAAKEIGENSCHAP in ZAAK (3) with waarde: 20231004.

In consumer API:

Fetch zaakeigenschap en eigenschap.
Use factory from api_models and create a ZaakEigenschap instance with the Eigenschap instance as its eigenschap value.
Try zaakeigenschap.get_waarde().

Expected behavior
zgw_consumers to be aligned with Open Zaak within its respective supported python versions.

@sergei-maertens
Copy link
Member

in my opinion this is a stupid construct in the standard for ZGW API's - the eigenschappen API design was rushed and not critically reviewed before accepting it. All other date/datetime formats in the API make use of the ISO-8601 international standard so I really fail to see why this format is allowed to be special.

That being said - I understand the challenges this creates. Feel free to submit a PR to fix this - in Maykin we are moving away to different API client organization and at some point we will re-evaluate how do deal with these domain data models.

On your end, you could monkeypatch this too by importing EIGENSCHAP_FORMATEN and setting a different cast function:

def weird_date_format(input: str):
    ...

EIGENSCHAP_FORMATEN ["datum"] = weird_date_format

@sergei-maertens sergei-maertens added bug Something isn't working good first issue Good for newcomers labels Oct 4, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working good first issue Good for newcomers
Projects
None yet
Development

No branches or pull requests

2 participants