open-formulieren / open-forms

Smart and dynamic forms
https://open-forms.readthedocs.io
Other
36 stars 27 forks source link

Sending of checkboxes as booleans via registration plugins (Objects/JSON, Stuf-ZDS/XML) considered problematic #4714

Open alextreme opened 2 weeks ago

alextreme commented 2 weeks ago

Thema / Theme

Plugins

Omschrijving / Description

Discussed with @LaurensBurger , we notice that via multiple clients that the sending of the selected checkboxes in a registration submission as booleans leads to workarounds via JSON-logic and gateways (DH/GZAC, Utrecht, Rotterdam/eSuite). We would like to see that checkboxes adhere to how radiobuttons work, because that does tend to work for receiving parties.

Example how OF currently submits the data of checkboxes:

"uitkeringenPartner": {
    "ww": false,
    "anw": false,
    "aow": false,
    "nee": false,
    "wao": true,
    "wia": false,
    "wajong": false,
    "bijstand": false,
    "ziektewet": false
}

However the prefered way would be as a single key/value:

uitkeringenPartner: wao

Multiple selections can then be sent as comma-separated values:

uitkeringenPartner: wao,ziektewet

Note that this is also a problem with the Stuf-ZDS backend via XML (eSuite, xxlnc)

Can be discussed with Laurens for further examples.

Added value / Toegevoegde waarde

No response

Aanvullende opmerkingen / Additional context

No response

joeribekker commented 1 week ago

Refinement: This requires a stakeholder. @alextreme any concrete Taiga issue?

I guess if we change it to the "other way" this would then cause similar questions (to change it back again) since it depends on the use case/municipality. The only solution is therefore to make the serialization behaviour configurable. This would then also make the change backwards compatible.

We can allow configuration on field (easy for users we think, hard for us), form (bit weird), registration-plugin (preferred) or application-level (maybe).

Estimate for registration-plugin configuration: 2 weeks

sergei-maertens commented 1 week ago

Ultimately this is a limitation because of formio and changing this has a big impact. I'm not saying to not do it, but I think 3 days is way too optimistic. 1-2 weeks is probably more realistic.

While I agree with the experienced problems, we should be really careful to use a consistent date type and not do simple mappings. Selectboxes have an inherent data type of list[str], even if only one option is selected, and I think we should really keep that consistent. If only one value is an option, you need to use a radio input.

alextreme commented 1 week ago

Refinement: This requires a stakeholder. @alextreme any concrete Taiga issue?

None yet, all linked stakeholders are working around this problem currently so there isn't an explicit request yet. It isn't pretty though

alextreme commented 1 week ago

@joeribekker confirmation from Laurens that Utrecht (Igor) and Rotterdam/Dimpact (Stef?) want this, but no Taiga issue yet. Rotterdam has mentioned banning checkboxes from all forms because it breaks the integration with the eSuite.

joeribekker commented 1 week ago

@alextreme Ok, well looking at the impact and no specification prior to this ticket, a stakeholder is really needed. So, this will be left on the backlog for now.