Reporting misconfigured handlers #312
Description
Description
Some handlers require configuration depending on elements. While they cannot be saved with incorrect configuration the elements referenced may be subject to modification (or removal) resulting in misconfigured handlers and failing jobs.
Steps to reproduce
We use the Digital Post-handler as an example:
- Create webform
- Add NemId CPR-element with key/id
recipientintended for CPR/CVR - Add other elements
- Add and configure OS2Forms Attachment-element
- Add and configure the Digital Post-handler correctly with above elements
New digital post handler jobs would now correctly send digital post
- Modify the element intended for recipient to have the key
cpr_number.
New jobs will now refer to the old element id, recipient, rather than cpr_number resulting in failed jobs. Furthermore, if users checks the Digital Post-handler configuration by clicking 'edit' on the handler it will look like it is configured correctly resulting in users just cancelling rather than re-saving the handler.
This is not limited to the Digital Post-handler. The following handlers have the same issue or variations of it:
More may exist
Proposal
An OS2FormsHandler-interface involving a validateConfiguration(...) method alongside a OS2Forms Handlers module that when visiting a webform loops over added handlers invoking the validateConfiguration(...)-method for each of them.
Any configurations that do not validate should then result in some sort of indication explaining which handlers are misconfigured and how.
Validation could include checking
- Elements existing
- Paths to files being correct
- Other references existing
For handlers we do not control we could consider wrapping them with the only change being the addition of the above validation method.
Furthermore, handler configurations that include selects should have an 'empty'-option to indicate that it is not configured.
Footnotes
-
Involves a reference to a flow by id which is probably unlikely to change. ↩