Provide a way to specify multiple possible sources of input for Zaak-initiator

[LaurensBurger]

Thema / Theme

Form designer

Omschrijving / Description

As a form designer i want to be able to create a form that contains identical initiators in separate parts of the forms. This will allow me to create forms for multiple "groups" instead of having to create unique forms for each.

Scenario: form "Request a event permit". This form can be used by businesses and citizens to request a permit to organize a event.

Step 1 contains 2 almost identical groups which are shown depending on the "auth": citizenGroup postcodeDigiD housnumberDigiD streetDigiD cityDigiD ...

businessGroup postcodeeHerkenning housnumbereHerkenning streeteHerkenning cityeHerkenning ...

Both groups contain components mapped with the same initiators.

In this scenario business submissions are generated with the correct mapping - but the citizen submission are "empty" because empty values from the business group overwrite the data from the citizen group.

As a form designer i want Open Forms to informed me about the fact is have set duplicate initiators - and if i know Open Forms will not overwrite a initiator that contain data with one that is empty i can build these forms.

[joeribekker]

@LaurensBurger can you elaborate:

1) Is the data overwritten because the property names/keys/eigenschapsnaam are identical or...? 2) Why are you not prefixing the property names? Is there a reason you want these to be the same?

[LaurensBurger]

1. No - they only share the same initiator. It seems the structure of the data is the deciding factor which value is used to generate the submission (lowest initiator overwrites all previous)
2. changed the property names in the initial issue - but these do not play a role.

[sergei-maertens]

For my context - is this the issue from Venray / Ger V.?

[LaurensBurger]

Yes - but also Utrecht (stuf-zds)

[sergei-maertens]

@joeribekker we started discussing this in the office at some point, but didn't manage to finish that. Basically it's a bit ambiguous what to do when multiple form variables are mapped to the same registration attribute, and there are a number of edge cases to consider:

• "ignore" empty and only take the filled in values... but
• what if components are deliberately hidden and empty and that has meaning for the registration... which makes me consider
• what about clearOnHide option
• this mechanism should be broader and apply to all registration backends in a consistent way, but for other backends (like objects) API instead of overwriting you may want to merge those options together into a list
• what if additional processing is required?
• we definitely need to handle the default / fallback case

I already veto'ed using Django template expressions since that pulls too many potential problems into scope that we don't condone, yet would expose to users and going back on that would mean breaking changes. Instead, we need an intuitive user interface that's very specific to the needs.

There are two aspects here as far as I understand:

1. there's no possibility to map multiple variables/components to the same registration attribute and only conditionally take one of them (i.e. citizen (DigiD) / company (eHerkenning) / anonymous form)
2. it's not clear that these overwrites will happen

For 2, I hope we can address this by moving the registration configuration outside of the component modal and into the variables tab, like we currently do for the objects API. This would also make it possible to add warning icons/detection for when multiple variables map to the same registration plugin + attribute combination. This is assuming that we don't "fix" the current behaviour.

For 1, we need to figure out how we can solve this. being able to select a fallback variable is not sufficient since that only gives you two levels, while in the case of Venray they need at least 3 levels which makes it a "generic" pattern.

[joeribekker]

So, the conclusion here is that:

1. We either do not support multiple of the same registration attribute
2. We allow the user to indicate what he wants to do in case there are multiple of the same registration attribute: a) overwrite by last one (current behaviour), b) pick the one that is not empty, c) concatenate into an array

For 2b: If both are filled, the behaviour should fall back to a)

This should be part of the registration-tab, where you edit the options for a field in the registration column. However, this is not possible (yet) for ZGW/StUF-ZDs. So, this ALSO requires us to move the ZGW/StUF-ZDS registration into the variables tab, which is in line with what we wanted anyway.

If there are 2 initiators, there should be a message saying so in the registration modal for the field details. If you change the behaviour in 1 field it should be changed in the 2nd field as well.

Estimate: 4 weeks

[joeribekker]

@StefSchots1993