Implement runtime file component registration config resolution - #6271
Conversation
| document_type_configuration = file_component.get("registration", {}).get( | ||
| "documentType", {} | ||
| ) | ||
| _document_type_description = document_type_configuration.get("description", "") | ||
| _catalogue = document_type_configuration.get("catalogue", {}) | ||
| if ( | ||
| _document_type_description | ||
| and (_catalogue_domain := _catalogue.get("domain")) | ||
| and (_catalogue_rsin := _catalogue.get("rsin")) | ||
| ): |
There was a problem hiding this comment.
this is set up very defensively on purpose - we don't have proper backend validation yet for component configuration and have to deal with legacy component configurations too
5b905bc to
23b0b1f
Compare
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #6271 +/- ##
=======================================
Coverage 97.07% 97.07%
=======================================
Files 865 866 +1
Lines 32700 32756 +56
Branches 2975 2981 +6
=======================================
+ Hits 31743 31799 +56
Misses 646 646
Partials 311 311 ☔ View full report in Codecov by Harness. 🚀 New features to boost your workflow:
|
aa921b0 to
4ced948
Compare
cc51f68 to
9cb9e2a
Compare
|
@annashamray @SonnyBA whomever gets first to review this, I think it's best to go commit-by-commit |
9cb9e2a to
b6724e4
Compare
| if (!componentDraft.registration) { | ||
| componentDraft.registration = {}; | ||
| } | ||
| if (!componentDraft.registration.documentType) { | ||
| componentDraft.registration.documentType = {}; | ||
| } | ||
| componentDraft.registration.documentType.catalogue = catalogue; | ||
| componentDraft.registration.documentType.description = description; | ||
| }); |
There was a problem hiding this comment.
Should we empty the other values (informatieobjecttype) that won't be used whenever this action is performed? Only assigning these values might give the impression that the other fields might still be used (if those were filled in before) while they're not.
There was a problem hiding this comment.
no I'm deliberately not doing that, in case something goes wrong that we can still reconstruct what the original situation was. The documentation/comments make it clear that the new situation is preferred if it's available, and this matches the behaviour of the registration plugin configuration options.
annashamray
left a comment
There was a problem hiding this comment.
Just a couple small remarks
This one exposes the file-component configuration options.
…pe description For the components that don't use the default specified document type from the plugin settings, it's reasonable to assume that they will use at least the same catalogue for the file component uploads. A copy function to the components allows doing this in bulk, after which only the document type description itself may still need tweaking. This commit needs to be backported to 3.5 to allow migrating/preparation for the 4.0 upgrade. From 4.0 onwards, we should move this config out of the component registration options entirely and could possibly also offer a dropdown to select the document type.
Needs to be backported to 3.5 as well.
... with a companion hook so that we can load the available document types in an optimized/efficient way.
b6724e4 to
68a81b9
Compare
…ile-component-doctype-resolution Runtime file component doctype resolution (#6271 backport)
Closes #6269
Changes
The
filecomponent now supports registration configuration where the catalogue identifier and document type descrition are specified. This is paired against the configured API group's catalogi API service and resolves into the correct version of a document type for a given submission.Additionally, I've added some optimization to avoid looking up the same catalogue and/or document types over and over if multiple similar configurations are provided.
Finally, the file component configuration is quite cumbersome, so I added an option to copy registration plugin options into the components which we can do in JS quite easily, that should reduce the impact for form builders.
Problem detection with mis-matched configuration is deferred and will be implemented as part of #6262
I verified that uploads inside repeating groups are also properly picked up in the component table.
Checklist
Check off the items that are completed or not relevant.
Impact on features
Dockerfile/scripts
./binfolderCommit hygiene
Documentation