Zaaktype/Documenttype urls migration tool#6268
Merged
sergei-maertens merged 4 commits intoMay 21, 2026
Merged
Conversation
sergei-maertens
added
the
needs-backport
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6268 +/- ##
==========================================
+ Coverage 97.07% 97.10% +0.03%
==========================================
Files 866 868 +2
Lines 32760 33117 +357
Branches 2982 3045 +63
==========================================
+ Hits 31802 32159 +357
Misses 646 646
Partials 312 312 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
sergei-maertens
force-pushed
the
feature/6262-zaaktype-documenttype-urls-migration-tool
branch
10 times, most recently
from
3f557d2 to
44759ea
Compare
Member
Author
I don't think there's anything to do here - it's a lot of work to support this and there are no real benefits:
|
sergei-maertens
force-pushed
the
feature/6262-zaaktype-documenttype-urls-migration-tool
branch
from
44759ea to
a8e56bb
Compare
annashamray
approved these changes
May 21, 2026
Contributor
There was a problem hiding this comment.
I've tested locally such cases:
- file component:
- correct legacy url
- incorrect legacy url
- registration backend
- zgw - correct legacy url
All work as expected
I've reviewed code and looked at test cases and just have a couple minor remarks, which are nice to have
The migrator migrates legacy URL references to document types and case types to their 'pointers': the description of the document or the identification of the case type, combined with the catalogue they belong to (domain + rsin). The migrator has a number of phases: - file upload components processing (the shittiest / least complete) - objects api registration backends - zgw api registration backends - objects API groups **File upload components** The registration options of a component may have an override for the document type, stored as a URL reference. #6269 added support for indirect references (catalogue + description). The migrator only touches components that have a legacy URL and *no modern* config yet. It looks up the catalogue + description of the document type and stores it, but does not validate that this catalogue matches (all of) the registration backend configuration, as that gets insanely complex and will cause problems. The long term idea here is to *move* that config from the component to the registration backend options itself anyway. **Objects API registration backends** Similarly here, there are three document types with a legacy and modern config. We don't touch the modern config, if present. Legacy URL references are resolved to their catalogue and description, and the coherence of all resolved catalogues in the whole backend config is checked (all documents must exist within the same catalog). If a catalog is already configured in the options, it is taken into account. If not, the catalog is written - we do not assume anything based on the related API group and instead make the config explicit per form. **ZGW API registration backends** Similar to Objects API, except here we consider the case type and document type references/legacy URLs. We don't touch modern config here either, and again validate the coherence: - doc type and case type must belong to the same catalogue, and match any pre-existing catalogue configuration - the doc type must be related to the specified case type. This may be tricky based on validity dates of these objects and on which day the migration tool is ran, but failures during migration would probably also manifest at runtime We don't touch the embedded object types configuration yet inside the ZGW APIs - that's also legacy, but a modern alternative is not yet available and honestly this migrator and commit message are huge already. **Objects API groups** Also at the group level legacy URLs (and modern replacements) can be present for the three relevant document types. These are updated the same way like the backend options - don't touch modern config, and resolve what is there to resolve and still missing. A management command is added that runs in dry-run mode by default. It just makes the changes and then rolls back the DB transaction - this way you can dry-run and run it as a diagnostic tool to inform the functional administrators which forms are problematic and need to be fixed manually before the migration tool can run.
I'm sure I missed some edge cases, but we'll find out about those when running the tool in diagnostic mode for real on test environments.
sergei-maertens
force-pushed
the
feature/6262-zaaktype-documenttype-urls-migration-tool
branch
from
a8e56bb to
b156b91
Compare
sergei-maertens
deleted the
feature/6262-zaaktype-documenttype-urls-migration-tool
branch
sergei-maertens
added a commit
that referenced
this pull request
May 21, 2026
The migrator migrates legacy URL references to document types and case types to their 'pointers': the description of the document or the identification of the case type, combined with the catalogue they belong to (domain + rsin). The migrator has a number of phases: - file upload components processing (the shittiest / least complete) - objects api registration backends - zgw api registration backends - objects API groups **File upload components** The registration options of a component may have an override for the document type, stored as a URL reference. #6269 added support for indirect references (catalogue + description). The migrator only touches components that have a legacy URL and *no modern* config yet. It looks up the catalogue + description of the document type and stores it, but does not validate that this catalogue matches (all of) the registration backend configuration, as that gets insanely complex and will cause problems. The long term idea here is to *move* that config from the component to the registration backend options itself anyway. **Objects API registration backends** Similarly here, there are three document types with a legacy and modern config. We don't touch the modern config, if present. Legacy URL references are resolved to their catalogue and description, and the coherence of all resolved catalogues in the whole backend config is checked (all documents must exist within the same catalog). If a catalog is already configured in the options, it is taken into account. If not, the catalog is written - we do not assume anything based on the related API group and instead make the config explicit per form. **ZGW API registration backends** Similar to Objects API, except here we consider the case type and document type references/legacy URLs. We don't touch modern config here either, and again validate the coherence: - doc type and case type must belong to the same catalogue, and match any pre-existing catalogue configuration - the doc type must be related to the specified case type. This may be tricky based on validity dates of these objects and on which day the migration tool is ran, but failures during migration would probably also manifest at runtime We don't touch the embedded object types configuration yet inside the ZGW APIs - that's also legacy, but a modern alternative is not yet available and honestly this migrator and commit message are huge already. **Objects API groups** Also at the group level legacy URLs (and modern replacements) can be present for the three relevant document types. These are updated the same way like the backend options - don't touch modern config, and resolve what is there to resolve and still missing. A management command is added that runs in dry-run mode by default. It just makes the changes and then rolls back the DB transaction - this way you can dry-run and run it as a diagnostic tool to inform the functional administrators which forms are problematic and need to be fixed manually before the migration tool can run. Backport-of: #6268
Member
Author
12 tasks
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
2 participants
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.
Closes #6262
Changes
[skip: e2e]
Checklist
Check off the items that are completed or not relevant.
Impact on features
Dockerfile/scripts
./binfolderCommit hygiene
Documentation