Objecttype v2 mapping: Upload in repeating group "replaces" all other data in repeating group on submit #4689
Assignees
Labels
needs-backport
Fix must be backported to stable release branch
owner: den-haag
topic: repeating group
waiting for approval
An estimate was made but the stakeholder still needs to approve it.
Milestone
Comments
LaurensBurger
added
bug
triage
LaurensBurger
changed the title
joeribekker
removed
the
triage
joeribekker
added
the
needs-backport
joeribekker
added
owner: den-haag
waiting for approval
|
Estimate: 2-3 days |
|
Akkoord is gisteren gegeven door Teun Winkelmolen, in Utrecht. |
sergei-maertens
added a commit
that referenced
this issue
Jan 29, 2025
sergei-maertens
added a commit
that referenced
this issue
Jan 29, 2025
Moved the file component key/value processing to the mapped variable processing instead of special casing this in the registration handler, since we will need access to the component types to handle editgrids which have file uploads inside, as these have different data paths *and* will require recursion as well since there can be editgrids inside editgrids that have this problem. The alternative is special casing repeating groups too, which breaks the mechanism to do component-specific post-processing in the dedicated function. This also updates the query for the submission variables so that if we have a more exact data path for an upload (inside a repeating group) that we use that instead of messing with the container editgrid which incorrectly gets replaced now. For uploads *not* in repeating groups, this data path is empty because it's identical to the variable key, so we can coalesce there at the DB level to calculate this in a unified way. See also #2713 that highlights the difficulties with how file uploads are now processed, which requires some proper re-structuring.
sergei-maertens
added a commit
that referenced
this issue
Jan 29, 2025
Fixed/added some type definitions to make it easier to reason about the data being operated on.
sergei-maertens
added a commit
that referenced
this issue
Jan 29, 2025
We must look up the uploads in the url map and replace only the file component nodes in the item values rather than the whole repeating group. This also needs to recurse, since in theory the repeating group can have another repeating group inside it.
10 tasks
sergei-maertens
added a commit
that referenced
this issue
Jan 30, 2025
sergei-maertens
added a commit
that referenced
this issue
Jan 30, 2025
Moved the file component key/value processing to the mapped variable processing instead of special casing this in the registration handler, since we will need access to the component types to handle editgrids which have file uploads inside, as these have different data paths *and* will require recursion as well since there can be editgrids inside editgrids that have this problem. The alternative is special casing repeating groups too, which breaks the mechanism to do component-specific post-processing in the dedicated function. This also updates the query for the submission variables so that if we have a more exact data path for an upload (inside a repeating group) that we use that instead of messing with the container editgrid which incorrectly gets replaced now. For uploads *not* in repeating groups, this data path is empty because it's identical to the variable key, so we can coalesce there at the DB level to calculate this in a unified way. See also #2713 that highlights the difficulties with how file uploads are now processed, which requires some proper re-structuring.
sergei-maertens
added a commit
that referenced
this issue
Jan 30, 2025
Fixed/added some type definitions to make it easier to reason about the data being operated on.
sergei-maertens
added a commit
that referenced
this issue
Jan 30, 2025
We must look up the uploads in the url map and replace only the file component nodes in the item values rather than the whole repeating group. This also needs to recurse, since in theory the repeating group can have another repeating group inside it.
sergei-maertens
added a commit
that referenced
this issue
Jan 31, 2025
sergei-maertens
added a commit
that referenced
this issue
Jan 31, 2025
Moved the file component key/value processing to the mapped variable processing instead of special casing this in the registration handler, since we will need access to the component types to handle editgrids which have file uploads inside, as these have different data paths *and* will require recursion as well since there can be editgrids inside editgrids that have this problem. The alternative is special casing repeating groups too, which breaks the mechanism to do component-specific post-processing in the dedicated function. This also updates the query for the submission variables so that if we have a more exact data path for an upload (inside a repeating group) that we use that instead of messing with the container editgrid which incorrectly gets replaced now. For uploads *not* in repeating groups, this data path is empty because it's identical to the variable key, so we can coalesce there at the DB level to calculate this in a unified way. See also #2713 that highlights the difficulties with how file uploads are now processed, which requires some proper re-structuring.
sergei-maertens
added a commit
that referenced
this issue
Jan 31, 2025
Fixed/added some type definitions to make it easier to reason about the data being operated on.
sergei-maertens
added a commit
that referenced
this issue
Jan 31, 2025
We must look up the uploads in the url map and replace only the file component nodes in the item values rather than the whole repeating group. This also needs to recurse, since in theory the repeating group can have another repeating group inside it.
sergei-maertens
added a commit
that referenced
this issue
Jan 31, 2025
Moved the file component key/value processing to the mapped variable processing instead of special casing this in the registration handler, since we will need access to the component types to handle editgrids which have file uploads inside, as these have different data paths *and* will require recursion as well since there can be editgrids inside editgrids that have this problem. The alternative is special casing repeating groups too, which breaks the mechanism to do component-specific post-processing in the dedicated function. This also updates the query for the submission variables so that if we have a more exact data path for an upload (inside a repeating group) that we use that instead of messing with the container editgrid which incorrectly gets replaced now. For uploads *not* in repeating groups, this data path is empty because it's identical to the variable key, so we can coalesce there at the DB level to calculate this in a unified way. See also #2713 that highlights the difficulties with how file uploads are now processed, which requires some proper re-structuring. We must look up the uploads in the url map and replace only the file component nodes in the item values rather than the whole repeating group. This also needs to recurse, since in theory the repeating group can have another repeating group inside it. Backport-of: #5059
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Product versie / Product version
2.6.x
Customer reference
DH
Omschrijf het probleem / Describe the bug
When "Bijlage informatieobjecttype" is set and a upload is present in a repeating group it replaces all values in the repeating group with just the result of the attachment upload:
json output with upload:
{ "type": "https://objecttypen.nl/api/v2/objecttypes/6e3a6f27-d248-46eb-853d-1373a1b9c6b0", "record": { "typeVersion": 2, "data": { "step": [ "https://openzaak.nl/documenten/api/v1/enkelvoudiginformatieobjecten/f9699f02-24fd-4799-8fcf-8c2aac434de0" ] }, "startAt": "2024-09-20" } }output no upload:
{ "type": "https://objecttypen.nl/api/v2/objecttypes/6e3a6f27-d248-46eb-853d-1373a1b9c6b0", "record": { "typeVersion": 2, "data": { "step": [ { "tekstveld": "1", "1tekstveld": "a", "eMailadres": "foo@bar.com", "bestandsupload": [] } ] }, "startAt": "2024-09-20" } }The text was updated successfully, but these errors were encountered: