Roadmap

The Open Forms roadmap describes broader topics that will be picked up in the nearby future.

As with most software projects, the codebase of Open Forms grows dynamically, driven by user stories, user feedback and developer experience. Inevitably, some technical debt is created and needs to be addressed. This is included in our roadmap to keep Open Forms a healthy and developer-friendly project.

The roadmap also offers some context to smaller issues that might linger a bit, waiting to be picked up in a broader topic.

Backend

Formio integration rework

Status: in progress

Currently, Open Forms is tightly coupled with Formio.js. There are a number of codepaths that directly introspect Formio definitions in places you wouldn’t immediately expect, leading to code that is hard to maintain and reducing flexibility in the available components.

The rework still only aims at supporting Formio.js, but the integration will be scoped to a single openforms.formio package. All other apps/modules/packages shall operate on an abstraction on top of that. This should make it easier to develop on Open Forms without intricate Formio.js knowledge.

Template context rework

Status: not planned yet

The Django template system is used in a number of places, such as confirmation e-mails, confirmation page content blocks etc. These templates are evaluated with the submission data.

The context for these templates requires some server-side controlled variables and the submission data is injected on top of that, polluting the top-level context namespace.

We should make an effort to migrate this data (with keys controlled by form designers) into a separate namespace to prevent surprises. This is a tricky change, as it may be a breaking change for existing templates.

This also aligns with the following topic.

API documentation

Status: not planned yet

Open Forms makes extensive use of JSONField in the database, which by default doesn’t provide much information in the API schema. On top of that, we typically do actually validate the schema of this JSON data using serializers, but this is not always reflected in the generated OAS 3 API schema.

Part of the reason for that is that the schema varies with a selected plugin, so we are looking at polymorphic schema’s. To provide better upfront documentation, we should explicitly declare these serializers as being polymorphic through drf-polymorphic.

API formatting

Status: not planned yet

Python’s style guide prescribes (variable) names in snake_case, while the Javascript world (and JSON APIs) typically use camelCase. Additionally, the Dutch API strategy settles on camelCase.

Open Forms uses a library djangorestframework-camel-case to convert between the two, but this proves to be challenging when dealing with user-supplied keys or JSONField content that should be left untouched.

The drf-camel-case library has some options to (globally) ignore some field names, but this is not flexible enough and will cause confusion later down the road.

We should explore possible improvements to drf-camel-case or completely other approaches do deal with the camel-case/underscore conversions.

Health checking/plugin status check

Status: not planned yet

The internal page to check the (configuration) status of various plugins currently checks all plugins sequentially and leads to a slow page.

This should be optimized to only consider enabled plugins and work asynchronously.

Full submission-data validation using Formio.js

Status: not planned yet

Formio.js allows you to declare validation rules, which are evaluated client-side. However, someone manipulating the APIs can bypass these to some extent. The submission completion endpoint should evaluate the same validation rules as Formio does client-side.

This is a topic to investigate. One option that has come up, is to run a nodejs backend server to use the actual Formio.js code to run the validations, called by the Python backend. Implementing these validations in Python will probably be too much work and error-prone.

Additionally, all the form-level logic should also be (re)-evaluated to detect inconsistencies.

Frontend

Use of design tokens

Status: well underway

Components need to be adopted so we can lift on existing design tokens. Colors have almost all been converted and can be overridden by themes.