feat: FORMS-2500 Decouples formio modules from CHEFS #1736

jasonchung1871 · 2025-07-24T01:24:52Z

Description

This feature introduces modularity by decoupling FormIO components from the application core. Form modules, each versioned independently, can now be injected at runtime with configurable builder behavior (categorization, component enablement, etc.).

Details

Each form version maps to a specific form module version, enabling backward compatibility.
Admins can manage form module sources and configurations via the dashboard.
Fine-grained access control allows admins to specify which identity providers (IDPs) can use which form modules.

Developer Use Case

Third-party developers may leverage these endpoints to:

Retrieve the appropriate form module for a given form.
Render forms externally using their own renderer.
Submit data via API without relying on the core UI.

Type of Change

feat (a new feature)

build (change in build system or dependencies)
ci (change in continuous integration / deployment)

Checklist

I have read the CONTRIBUTING doc
I have checked that unit tests pass locally with my changes
I have run the npm script lint on the frontend and backend
I have added tests that prove my fix is effective or that my feature works
I have added necessary documentation (if appropriate)
I have approval from the product owner for the contribution in this pull request

Further comments

Modified the vuex store to include a value called builder which formio builder uses to generate the available components. There is an initial value for this builder and it can be updated to register plugins at runtime. In this example, the checkmatrix component is imported from an external location, then the component is registered, then the form is re-rendered.

The administrator can now import modules from any URL. You can manage each form module's plugin name and the idir access for that module. You can also view all versions for that form module, and manage each form module version. You can update the import data or external URI, although you should not do this unless the application import data format changes or if a URL is no longer working. You should always be importing a form module version from the form module management page to replace an existing version. Any versioned forms will continue to use the older form module version so that they can be viewed in the same way that they were submitted. Related issue: FORMS-69

Was missing the userType when loading form modules. Moved a large section of code into its own function.

Form modules can now be loaded when viewing a submission.

When importing a new form module, the form module version fields are now reset instead of loading what was previously loaded. Tests include the toggleFormModule.

Separated the parsing of form module version parsing, and cleaned up some code.

Some urls were generated with undefined ids, that has been fixed. Updated the kitchensink test for Cypress to "load modules" before proceeding with the form submission. Added an E2E test that authenticates a test user that should exist in your keycloak instance.

E2E test for importing a form module completed with keycloak authentication. Fixed some test cases in the front end.

Added E2E tests for form module management. - Get form module - Import form module version - Update form module version - Update form module - Toggle form module Fixed a bug with form module versions list returning outdated form module versions from the form module rather than the list.

Migrates form module management components from Vuex to Pinia for state management and integrates vue-i18n for localization. Updates UI elements to use localized strings, improves reactivity, and restructures logic for better maintainability. Removes obsolete files and updates related services, router, and tests to support the new store structure.

Replaces Keycloak with JWT service for admin route protection in form module routes. Refactors notification store usage, updates form module and version management components for improved reactivity and UI consistency, and fixes various minor bugs and typos. Also updates internationalization keys and improves expansion panel usage in the UI.

Improves logic for loading form modules by selecting only the latest version and deduplicating external URIs. Adds support for a 'config' field in form module versions at both the database and model levels, and updates usage in the frontend to handle this new field. Also fixes several Vue reactivity and reference issues in designer and management components.

Replaces all usage of 'importData' with 'config' for form module version configuration across frontend, backend, tests, and fixtures. Updates database schema, models, and migration to remove 'importData' and standardize on 'config' as a JSON string. Adjusts UI, store, and utility constants to support the new structure and updates test cases and seed data accordingly.

Refactored unit tests for form module controller, service, and routes to improve consistency and readability. Updated import paths to use tilde (~) in frontend tests, replaced Jest with Vitest in formModuleService.spec.js, and standardized mock setups. Adjusted route and endpoint count assertions to reflect new routes. Minor formatting and code style improvements applied throughout.

Introduces validation middleware for formModuleId and formModuleVersionId route parameters and integrates them into form module routes. Updates the publishDraft logic to associate only the latest version of each form module. Adds and extends unit tests for form module routes, controller, and service to cover new validation and logic.