Reverse mapping of form variables to verzoektype and enhanced data handling

[joeridiederen]

Thema / Theme

Frontend

Omschrijving / Description

This RFC proposes a restructured approach to how form variables (keys) in Open Forms are mapped to the corresponding keys in an object type (verzoektype). Instead of the current non-intuitive, form-variable-driven mapping that often requires complex JSON logic, we introduce a verzoektype-driven approach. This interface change will display verzoektype fields (e.g., on the left side) and allow users to fill them with the appropriate form variables.

The desired outcome is to empower users to construct fields by composing multiple form variables using the existing template functionalities in Open Forms, such as variable placeholders {{ variable }}, conditional logic ({% if %}, elif, and, or, etc.), and formatting options.

This approach also streamlines schemas and reduces the reliance on JSON logic for value convergence and replacement.

Additionally, this RFC describes enhancements to handle array and object data types more elegantly, as well as an option to conditionally omit empty values to avoid unnecessary validation issues.

Added value / Toegevoegde waarde

• By reversing the mapping order (from request-type fields to form variables), users gain a clearer overview of which fields need which data, reducing confusion and complexity.
• The ability to combine multiple form variables into a single verzoektype-field allows for improved flexibility. For instance, assembling a "full name" field from multiple authentication methods or constructing a "description" field from various form variables for posting to backend systems.
  • With variables composed directly in the request-type schema fields, the reliance on JSON logic for transformations diminishes, simplifying form configurations and maintenance.
• Improved handling of array and object data types ensures better compatibility with external systems that expect these formats (e.g., Dimpact’s PodiumD, ZAC). This includes correct parsing, validation, and mapping, resulting in fewer integration challenges. For example: an optional object with required values is not correctly processed at the moment (2.7.9 alert).
• Introducing a checkbox “Do not post if empty” for each mapped field helps avoid unnecessary schema keys from being posted. This prevents validation issues in scenarios where “oneOf” constraints exist (e.g., either KvK or BSN must be present, but not both).

Aanvullende opmerkingen / Additional context

Currently, JSON logic is heavily used (at least in Rotterdam) to adapt form variables to match request-type field formats. By shifting to a verzoektype-driven interface and leveraging template syntax directly in the fields, the complexity of transformations will be significantly reduced.

[sergei-maertens]

Refinement: the big picture is clear, the implementation details will be fleshed out when we pick this up.

[sergei-maertens]

Estimate: 5 weeks (including 2 weeks timebox for editor prototyping/research)