Skip to content

Feat: add an "Email" form destination - #83

Open
ccailly wants to merge 3 commits into
mainfrom
feat_email_destination_12
Open

ccailly wants to merge 3 commits into
mainfrom
feat_email_destination_12

Conversation

@ccailly

@ccailly ccailly commented Nov 3, 2026 •

Copy link
Copy Markdown
Contributor

Checklist before requesting a review

  • I have performed a self-review of my code.
  • I have added tests (when available) that prove my fix is effective or that my feature works.
  • I have updated the CHANGELOG with a short functional description of the fix or new feature.
  • This change requires a documentation update.

Description

Add an "Email" form destination that sends a customized email when a form is submitted. It can be enabled from the plugin configuration page, under the new "Destinations" section.

  • Subject and body reuse the core Title and Content fields: they accept form tags, and the body supports auto configuration.
  • Recipients come from answers (email, requester, observer and assignee questions), specific users or groups, the form filler or their supervisor, and additional email addresses typed as tags (same dropdown as the actors fields of the ITIL objects).
  • Inactive, deleted or expired users and groups with notifications turned off are skipped, as for GLPI notifications.
  • Emails go through the notification queue, one per recipient. The body is sanitized, and a sending failure is logged without cancelling the submission.
  • The config form, export, import and clone follow the native ITIL destinations.

Screenshots (if appropriate):

config

email destination

@ccailly
ccailly force-pushed the feat_email_destination_12 branch 2 times, most recently from e786308 to 5a8382f Compare November 3, 2026 16:05
Add a form destination that sends a customized email when a form is
submitted, behind a new "Email destination" switch on the plugin
configuration page.

- Subject and body reuse the core Title and Content fields, so they
  accept form tags and the body supports auto configuration. They are
  laid out as form rows, the body label sharing the line of the
  "Auto config" switch.
- Recipients come from answers (email, requester, observer and assignee
  questions), specific users or groups, and free email addresses typed
  as tags, as in the actors fields of the ITIL objects.
  Inactive, deleted or expired users and groups with notifications
  turned off are skipped, as for GLPI notifications.
- Emails go through the notification queue, one per recipient. The body
  is sanitized, and a sending failure is logged without cancelling the
  submission.
- The config form, export, import and clone follow the native ITIL
  destinations.
The email of each group member was read with its own query, on every
submission and inside the answers transaction. The recipients are now
collected as user ids, then their default emails are fetched at once.
The recipients may come from an answer to an "Email" question, and the
body may contain free answers: anyone allowed to answer the form can then
have any text sent to any address. The config of the destination now
warns about it, more strongly when the form can be answered without
being authenticated.
@ccailly
ccailly force-pushed the feat_email_destination_12 branch from e3807db to 6ed4e13 Compare November 9, 2026 08:54
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant