Upgrade details to Open Forms 2.4.0
We do our best to avoid breaking changes, but at times we cannot guarantee that your configuration will keep working flawlessly. Open Forms 2.4.0 is such a release - and the manual interventions with context are documented here.
Check forms with duplicated steps
We now block duplicated form steps at the database level - if you have forms in your environment with non-unique steps, the upgrade will refuse to execute (or crash if you disable checks).
The check script is available since Open Forms 2.3.4, you can run it using:
python /app/bin/check_non_unique_steps.py
and it will report any problematic forms. These forms need to be updated manually to remove the duplicated steps.
DigiD/eHerkenning configuration
DigiD and/or eHerkenning configuration before Open Forms 2.4.0 required manually uploading the XML metadata file.
This file is now automatically retrieved, provided you configure the “(XML) metadata URL”. We cannot populate this URL on existing instances, so you need to configure this manually by navigating to:
Admin > Configuratie > DigiD-configuratie and
Admin > Configuratie > EHerkenning/eIDAS-configuratie
The field can be found under the “Identity provider” section.
Once these URLs are configured, the metadata file field and the identity provider ID will be automatically populated.
Our upgrade mechanism automatically generates the relevant CSP directives from your existing DigiD/eHerkenning configuration.
Note
Any previously uploaded metadata files continue to work as expected.
KVK Configuration
We’ve done some extensive code and configuration cleanups, and the KVK configuration may be affected by this. The service configuration for the “zoeken” and “basisprofiel” API’s has been merged into a single service. Normally this configuration update should have been performed correctly automatically, but we can’t rule out possible mistakes with more exotic configurations (e.g. when using API gateways).
⚠️ Please check and update your configuration if necessary - you can check this via: Admin > Configuratie > Configuratie overzicht and look for the KVK entries.
If you run into any errors, then please check your certificate configuration, API key
and validate that the API root does not include the v1/ suffix. An example of a
correct API root: https://api.kvk.nl/api/ or https://api.kvk.nl/test/api/.
Alert styling
We’ve refactored our alert styling to make use of the utrecht-alert component. This
effectively replaces the --of design tokens with the --utrecht ones. A backwards
compatibility layer is set up which will be dropped in Open Forms 3.0, so we recommend
updating your stylesheets.
There is no automatic data migration set up (yet).
Reference
The mapping below shows the NL Design System tokens populated from our custom tokens:
:root {
--utrecht-alert-warning-background-color: var(--of-alert-warning-bg);
--utrecht-alert-info-background-color: var(--of-alert-info-bg);
--utrecht-alert-error-background-color: var(--of-alert-error-bg);
--utrecht-alert-icon-error-color: var(--of-color-danger);
--utrecht-alert-icon-info-color: var(--of-color-info);
--utrecht-alert-icon-warning-color: var(--of-color-warning);
--utrecht-alert-icon-ok-color: var(--of-color-success);
}