Allow specifying the documents API in the objects API registration

[joeribekker]

Reference: PF-114

Thema / Theme

Frontend

Omschrijving / Description

See below for an updated list of tasks

• [x] Restructuring of configuration of Objects API into groups (like ZGW groups) including the Documents API
• [x] Remove global objecttype/documenttype configuration.
• [x] Add group selection in Objects API registration-tab on form-level
• [x] Restructuring of Objecttype selection from URL to dropdown with objecttype UUIDs, after selection of chosen group
• [x] Adjusting variable mapping, taking into account group choice (clear after changing choice - can be a popup).
• [ ] #4577
• [ ] Make the ZGW APIs registration consistent
  • [ ] Select zaaktype by storing the identificatie (or omschrijving?) and make the plugin fetch the relevant version to use
  • [ ] Select documenttype by storing the identificatie/omschrijving (check standard) and make the plugin fetch the relevant version to use

---

We should store the unique-attributes if possible, instead of the UUID, and not store URLs at all (except for the services ofcourse).

• Objecttype: uuid
• InformatieObjecttype: omschrijving + catalogus
• Zaaktype: omschrijving + catalogus
• RolType: omschrijving + zaaktype

To do so, it is proposed to add a management command to migrate from URLs to omschrijving + catalogus/zaaktype (as it requires API calls that can't be made in data migrations). This command should be run when upgrading from 2.7 to 2.8. There are two ways we could deal with this:

• Explicitly state the management command need to be run in the changelog, and we hope they will.
• Add an 2.7 -> 2.8 upgrade check iterating over the registration backend configurations and checking the management command was run (e.g. no more zaaktype field, but zaaktype_omschrijving + zaaktype_catalogus).
  • Should we add a mechanism to prevent the management command from running two times?

---

Tasks:

• [x] Backend should send a "display name" for the catalogus to the frontend
• [x] https://github.com/open-formulieren/open-forms/issues/4534
  • https://github.com/open-formulieren/open-forms/pull/4539
• [x] Update the Objects API configuration serializer (V1 and V2): add the catalogus_domein and catalogus_rsin fields, update business validation logic.
  • https://github.com/open-formulieren/open-forms/pull/4541
• [ ] Add a management command to upgrade existing Objects API configurations
  • https://github.com/open-formulieren/open-forms/pull/4536
• [x] Update Objects API registration plugin logic, to fetch the corresponding IOT URL based on the domein, RSIN and omschrijving. TypedDict definitions should also be updated.
• [x] Figure out what to do IOTs set at the ObjectsAPIGroup level (i.e. global defaults). They are here for convenience as users previously had to specify URLs which could be cumbersome. However, we know offer nice dropdowns for these IOTs, so probably we could remove these global defaults. However, this might require a data migration/management command.
• [ ] Add a Zaaktypen API list view:
  • https://github.com/open-formulieren/open-forms/pull/4498
• [ ] Update ZGW options UI: Use react-select dropdown for IOT (component is available from https://github.com/open-formulieren/open-forms/pull/4494), Zaaktype (component needs to be created and make use of the created Zaaktypen list view endpoint)
• [ ] https://github.com/open-formulieren/open-forms/issues/4344 (this should also use react-select dropdowns)
• [ ] Update the ZGW API configuration serializer: this shouldn't include any modifications of fields, only the validation of business logic.
• [ ] Add a management command to upgrade existing ZGW API configurations.
• [ ] Update ZGW API registration plugin logic, to fetch the corresponding IOT/Zaaktype URLs based on the omschrijving + catalogus/zaaktype.
• [ ] Figure out if the organisatie_rsin field on both the Objects and ZGW API registration needs to match the selected catalog RSIN? If so, probably it should be removed as we now store the catalogus_rsin? If so, should we check that the organisatie_rsin matches the catalogus_rsin?