[dcoffin88]

Summary

Introduces a new Templates plugin for creating, managing, and inserting reusable email templates with dynamic variables and placeholders.

Adds recipient-specific personalization for outgoing and scheduled emails, allowing each recipient to receive an individually customized message while maintaining proper Bcc privacy and delivery tracking.

Related Issues

This PR addresses the email template functionality discussed in:

#77 - Original discussion proposing reusable email templates and snippets.
#438 - Visual Template Builder plugin for rich HTML email creation.
#684 - Request for email templates to simplify composing recurring messages.

Changes

• Added an optional plugin enabled through Settings -> Plugins, with template management under Mail -> Templates.
• Create, edit, and delete templates containing Name, To/Cc/Bcc, Subject, and rich-text email content.
• Insert saved templates directly from the compose menu.
• Added an insertion dialog supporting localized dates, contact names, addresses, email addresses, phone numbers, and other contact fields.
• Custom Placeholders: Added a button to insert editable {{ add placeholder }} markers at the cursor position.
• Resolve variables when sending emails, including scheduled messages, using the sender's language and time zone.
• Generate individualized email content for every unique To, Cc, and Bcc recipient using their contact information.
• Prevent sending when required variables or placeholders are unresolved, preserve Bcc privacy, deduplicate recipients, and track partial deliveries to prevent duplicate sends.
• Extended plugin hooks, composer actions, and storage support for template functionality.
• Added backend and frontend tests covering templates, variable resolution, personalized delivery, and scheduled sending.

Screenshots

---

---

---

---

---

Testing

• Enabled the Templates plugin and verified template creation, editing, and deletion.
• Inserted saved templates and custom placeholders into the composer.
• Verified localized date, time, and contact variable resolution.
• Tested personalized email delivery to multiple To, Cc, and Bcc recipients.
• Confirmed Bcc privacy and duplicate-recipient handling.
• Verified that unresolved variables and unfilled placeholders prevent sending and display appropriate errors.
• Tested variable resolution in scheduled emails.
• Verified partial-delivery tracking and recovery without duplicate sends.
• Ran backend and frontend tests.

---

Contributor License Agreement

By submitting this pull request I confirm that:

• I have read and agree to the Contributor License Agreement.
• My contribution is my own original work (or I have identified any
  third-party material and confirmed it is compatible with the CLA).
• I have the right to submit this contribution under the terms of the CLA.

[maathimself]

Templates are on the roadmap as saved snippets: greetings, sign-offs and canned responses loaded into the composer. This PR goes further than that, and changes to core behavior need an issue first (CONTRIBUTING), so I'd like to split it.

Templates as a plugin: yes. Saving, editing and inserting templates from the composer, with variables filled in when the template is inserted (date, the recipient's name from the contact). That keeps everything in the plugin and the composer, with no change to how mail is sent.

Personalized delivery: not for now. Resolving content per recipient at send time changes the send path for every message: each send goes through a new content hook, one Send becomes one SMTP delivery per recipient (Bcc included), each copy gets its own Message-ID, so replies no longer thread together, and a stop partway through leaves a partially delivered message. As I read it, servers that don't save sent mail themselves would also get one Sent copy per recipient. That is mail merge, which I'm not planning to add to the core, partly because on a hosted instance it is also a bulk-mail tool. If you want to make the case for it, please open an issue rather than code.

Order. CONTRIBUTING asks for one open pull request per author, and #686 and #693 are open too. Let's finish #686 first; then a snippets-only version of this can follow, as this PR updated or a new one.