The database does not allow null values, but gebruikers_id can be None if both the NLX header and the JWT payload key user_id don't exist.

Internal error report: https://sentry.maykinmedia.nl/maykin-media/zrc-test/issues/257018/?query=is:unresolved

Issue occurred in CI for catalogi API: https://github.com/VNG-Realisatie/catalogi-api/pull/116/checks?check_run_id=1550996968#step:8:15503

Version 1.0.44 introduced the following: 22968a6#diff-aaa7048a6193623a30d02f47eb1c0ac30a3acc22684b5ea44da7e4e4ca66b2e8R33

This causes issues down the line when attempting to cache the reDoc view, because some filters from django_filters (such as ConcreteInFilter are locally declared (and thus can't be pickled).

This patch should be applied.

maykinmedia@20d9345

Zie commit 1aed75396b872014f844e3cae25a323bdfa87adc ter referentie

When using PolymorphicSerializer, running generate_schema fails due to some issues with polymorphisms and swagger2.0

AssertionError: #/definitions/zaak already exists

VNG-Realisatie/notificaties-api#14 flattens the structure of kenmerken to a simple key: value mapping instead of a list of objects. The notifications code should be updated to match this new format.

Currently vng api common is pinned to < Django 3.0, but 2.2 is end of life in April this year and this library currently blocks upgrading CMIS adapter and Open Zaak to 3.2 LTS.

Tasks

• Update the tox.ini envlist to support the following matrix of versions
  • Python 3.7 - Django 2.2
  • Python 3.8 - Django 2.2
  • Python 3.7 - Django 3.2
  • Python 3.8 - Django 2.2
• Update the Github CI workflow to support the same matrix
• Make the necessary changes to the package to support Django 3.2
• Resolve the Django 4 upgrade warning
• Update the package metadata to correctly reflect the supported versions
• Extra: see if we can add Python 3.9 and Python 3.10 support

Downstream issue from VNG-Realisatie/gemma-zaken#782 (comment)

Bug:
For actions = 'parial_update' notification is send twice
Notifications with other actions are correct

I see that #225 was merged and released via #226 as a minor release, but you did breaking changes that affect our projects.

Derived projects making use of vng-api-common (like https://github.com/open-zaak/open-zaak) are affected by this and you not adhering to semantic versioning. You are now forcing us to deal with massive changes in tooling in a minor release, and frankly, this is not acceptable.

Please yank the 1.11 release from PyPI and release this properly as 2.0, but it would also have been nice to check and give downstream projects time to test out these changes and adapt to them.

We should use constants instead of typing these over and over:

The notification component uses actions, like: 'list', 'read', etc.:
https://github.com/VNG-Realisatie/vng-api-common/pull/22/files#diff-fc3d84d47d024001d3713b8e75cdc904R51

And here we check for 'autorisations' as channel name. Maybe all "known" channel names should be in the project, just like the ComponentTypes enum is now:

https://github.com/VNG-Realisatie/vng-api-common/pull/22/files#diff-06900288ee127189c9c4ddc826634dddR95

Er wordt voor deze endpoint op het moment een verkeerde request body getoond:

Anna mentioned due to a bug in vng-api-common, nested serialization goes wrong if it fails.

We choose to be pragmatic and keep it as is, but would be nice if vng-api-common was updated :D

Originally posted by @joeribekker in VNG-Realisatie/notificaties-api#1

https://github.com/VNG-Realisatie/gemma-zaken-common/blob/c4e75bfbb1a89c1a67e4ddd5192900264437b141/zds_schema/management/commands/generate_swagger.py#L92-L95

Workaround was to add the urlconf here:

        generator = OpenAPISchemaGenerator(
            info=info,
            url=api_url,
            urlconf='demo_api.api.v2.urls'
        )

But I noticed the original code allowed for a version to be passed. Not sure if that worked tho.

Zie https://github.com/VNG-Realisatie/vng-api-common/pull/209/checks

Among others, this allows us to do point the schema to the appropriate urlconf.

DefaultSchemaView = get_schema_view(
    # ....
    urlconf='demo_api.api.v2.urls',
)

class SchemaView(ZDSSchemaViewMixin, DefaultSchemaView):
    pass

Currently it does, which is a pragmatic approach to not have to modify a lot of tests in downstream projects.

However, this should not silently pass, and you'd expect to only apply the validator to resources that provide the concept key in their response bodies.

Bijvoorbeeld inspectors (drf-yasg) directory hernoemen naar extensions (drf-spectacular)

Basically the cause behind this comment:

#27 (review)

The action attribute should not be needed at all, since it's a View and not a ViewSet but our permission approach expects the action attribute at all times.

There's a breaking change . encode and decode no longer operate on bytestrings, but on regular strings now. It's been dealt with in gemma-zds-client already.

In 1.4.5 it still is, in 1.5.0 it's not anymore, but it's Content-Type application/json.

The JWT payload attribute user_id is mandatory, see also: https://github.com/VNG-Realisatie/gemma-zaken/blob/master/docs/_content/standaard/standaard.md#autorisatie

Bijvoorbeeld bij /zaken/{uuid} in ZRC

See VNG-Realisatie/zaken-api#41 (review)