Improve ZGW registration optionx UX - add catalogue selection

[sergei-maertens]

Partially closes #4606

Changes

• Allow setting a (default) catalogue at the api group level, validating the configuration against the configured catalogi API
• Allow specifying a catalogue on the serializer (overriding the api group, if it is set)
• Validates the case type and document type against he catalogue, if it's provided (either on serializer or model level)
• Add additional tests for catalogue validation
• Add catalogue selection in UI

Checklist

Check off the items that are completed or not relevant.

• Impact on features

  • Checked copying a form
  • Checked import/export of a form
  • Config checks in the configuration overview admin page
  • Problem detection in the admin email digest is handled

• Release management

  • I have labelled the PR as "needs-backport" accordingly

• I have updated the translations assets (you do NOT need to provide translations)

  • Ran ./bin/makemessages_js.sh
  • Ran ./bin/compilemessages_js.sh

• Commit hygiene

  • Commit messages refer to the relevant Github issue
  • Commit messages explain the "why" of change, not the how

[codecov]

Codecov Report

Attention: Patch coverage is 98.05195% with 3 lines in your changes missing coverage. Please review.

Project coverage is 96.66%. Comparing base (bc1ac4d) to head (de55088).
Report is 14 commits behind head on master.

Files	Patch %	Lines
src/openforms/contrib/zgw/validators.py	83.33%	2 Missing and 1 partial ⚠️

Additional details and impacted files

@@            Coverage Diff             @@
##           master    #4609      +/-   ##
==========================================
+ Coverage   96.65%   96.66%   +0.01%     
==========================================
  Files         727      731       +4     
  Lines       24426    24526     +100     
  Branches     3218     3221       +3     
==========================================
+ Hits        23609    23709     +100     
  Misses        564      564              
  Partials      253      253              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[vaszig]

Shouldn't we put all these validators in the validators.py?

[sergei-maertens]

in my mind, validators.py is more intended for re-usable validators, and this validation helper is tied very strongly to the particular serializer that it's pretty much impossible to re-use.

These functions basically only exist to make the code a bit more readable, this could as well just have been directly implemented in def valiate(self, attrs): entirely, but that became such a huge chunk of code that I found it not maintainable anymore.

I also dislike the indirection created by moving private helper functions into different files, which requires me to click around more to see what the shape of data is actually like.

Then finally, validators.py are aimed at the django model layer, while these helpers are intended for DRF serializers. Unfortunately, these validators are not interchangeable (I tried building a generic solution but it gets real messy real quick). So, validators.py is used in the admin, while the serializer is used in the API endpoints used by the form designer.

[vaszig]

Understood and yes after your explanation makes sense.

[vaszig]

Again confused..why do we have two separate components (one in objectsAPI and one in ZGW)?Perhaps it has to do with my question above concerning the serializers in the backend.

[sergei-maertens]

both use the same generic components/admin/forms/zgw/CatalogueSelect, so they're both specializations of that one.

They are different because the registration plugins are different - objects API should not be aware of ZGW or vice versa. Additionally, the context of each select is different for each plugin, which can result in different form field labels, help texts or even catalogue selection options. In particular here, the catalogue select is disabled if no API group has been selected yet, and for Objects API the form field is objectsApiGroup, while for ZGW APIs the form field for the API group is zgwApiGroup. Additionally, the available options are loaded from their plugin-specific API endpoints.