Migrate API groups configuration to backend options#6305
Open
sergei-maertens wants to merge 7 commits into
Open
Migrate API groups configuration to backend options#6305sergei-maertens wants to merge 7 commits into
sergei-maertens wants to merge 7 commits into
Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6305 +/- ##
==========================================
- Coverage 97.07% 96.99% -0.09%
==========================================
Files 866 864 -2
Lines 32755 32674 -81
Branches 2981 2966 -15
==========================================
- Hits 31797 31692 -105
- Misses 646 668 +22
- Partials 312 314 +2 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Member
Author
|
Import/export of (old) forms exports can't be addressed here, because the API group is not present in the export and we're removing these fields from the existing groups. Users will need to re-generate the exports on 4.0. |
sergei-maertens
force-pushed
the
feature/4939-migrate-objects-api-groups-to-backend-options
branch
2 times, most recently
from
c01fcd6 to
717e154
Compare
sergei-maertens
force-pushed
the
feature/4939-migrate-objects-api-groups-to-backend-options
branch
from
a3415b8 to
a4e3c01
Compare
Member
Author
I analyzed our SAAS test and production environments and the conclusion is that barely anyone is using the catalogue configuration on the API group level (Objects API, ZGW). Most select the catalogue in the registration backend options. I can't tell what the situation is for on-prem environments due to not having access. This layering of catalogue information/defaults leads to a lot of complexity in the code base, and I believe we can safely migrate this automatically, given that: 1. Users are expected to use 3.5 to convert legacy URL configuration into modern configuration (catalogue + references) 2. 4.0 is already known to drop support for legacy URLs, so we can assume we only have to deal with modern configs 3. With no-one known to use legacy URLs (at the API group level), we don't need to do anything about the document description fields. Though, we can hide those in the admin and keep the runtime code from resolving them when they're set as a default, if that makes sense 4. A data migration can copy the group-level catalogue to each registration backend that uses this API group, but only if no explicit catalogue override is specified. Legacy URL migration during 3.5 will likely have populate a bunch already, so we expect this to have negligible impact. Only empty-ish configuration would get updated that relied on defaults, and we can copy all those over. This makes the migration and future enhancement a lot more manageable, which they currently aren't and block me for #6281
This is simpler because there are no case type or document type defaults at the group level, only the catalogue is relevant to be copied over.
A similar but simpler approach to the Objects API groups. In practice, the migration tool from 3.5 will likely already have set the catalogue on most, if not all backends, but it's good to make sure this is covered for unexpected edge cases.
This is obsoleted now that the catalogue is always stored in the registration backend options.
…API Group level This drops the support for the catalogue references and/or document type (defaults) at the API group level. The 3.5 release provides migration tooling and we ship a data migration that moves all configuration into the registration backend options instead.
The 4.0 upgrades will run a modified version of the migration tool as an upgrade check. To be able to detect unmigrated backends and API groups, we must still be able to query the legacy fields using the real models, which requires the field definitions to still be on the model.
sergei-maertens
force-pushed
the
feature/4939-migrate-objects-api-groups-to-backend-options
branch
from
a4e3c01 to
73c0c36
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Partly closes #4939 - best to get #6309 merged first
Changes
[skip: e2e]
Checklist
Check off the items that are completed or not relevant.
Impact on features
Dockerfile/scripts
./binfolderCommit hygiene
Documentation