>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3615583. --> Reported by: [jdleonard](https://www.drupal.org/user/80902) Related to !1 >>> <h2>Problem/Motivation</h2> <p>The module is currently a scaffold: it installs cleanly but defines no<br> entities, plugins, routes or permissions. Nothing else can be built &mdash; recipient<br> resolution, composition UIs, scheduling, tracking &mdash; until the core data model<br> exists and the extension points it depends on are defined.</p> <p>This issue establishes that foundation. It is deliberately high-level; the<br> detailed design happens in the plan attached to this issue.</p> <h2>Proposed resolution</h2> <p>Two revisionable content entity types, each fieldable and bundleable via a<br> config entity, plus three plugin types.</p> <p><strong>1. The <code>campaign</code> entity</strong> &mdash; the container and the<br> audience. Bundled by <code>campaign_type</code>.</p> <ul> <li>Name/title</li> <li>One or more messages</li> <li>Recipient logic &mdash; one or more <em>include</em> sets and one or more<br> <em>exclude</em> sets, each supplied by a Recipient plugin</li> <li>Scheduling &mdash; supplied by a Scheduling plugin</li> <li>Settings: track opens, track clicks</li> </ul> <p><strong>2. The <code>campaign_message</code> entity</strong> &mdash; one piece of<br> outgoing content. Bundled by <code>campaign_message_type</code>. Named with the<br> <code>campaign_</code> prefix because the Message module already claims the<br> <code>message</code> entity type ID, and that module is one we expect to<br> evaluate rather than avoid.</p> <ul> <li>Subject</li> <li>Preview text</li> <li>"Sent to" pattern &mdash; the display name on the outgoing message, e.g.<br> <code>[First] [Last]</code></li> <li>From name and from email</li> <li>HTML content</li> <li>Plaintext content (optional; generated from the HTML when absent)</li> <li>Web URL &mdash; the browser-viewable permalink</li> <li>Composition plugin, with its configuration</li> </ul> <p><strong>Both entity types are revisionable.</strong> A campaign's audience and<br> schedule, and a message's content, are all things a maintainer will want history<br> for &mdash; particularly once a campaign has been sent and the question becomes what<br> exactly went out.</p> <p><strong>3. A Recipient plugin type.</strong> Each plugin resolves to a set of<br> recipients. A campaign composes several, some additive and some subtractive, and<br> the module reduces the whole set to a final audience. Anticipated<br> implementations:</p> <ul> <li>Entity Segment &mdash; via <a href="https://www.drupal.org/project/entity_segment">entity_segment</a></li> <li>A literal list of email addresses</li> <li>A list of CRM Contacts, selected via Views Bulk Operations</li> </ul> <p><strong>4. A Composition plugin type.</strong> Each plugin owns a UI for<br> authoring the HTML body, and may optionally produce the plaintext alternative.<br> Candidate integrations:</p> <ul> <li><a href="https://www.drupal.org/project/easy_email">Easy Email</a></li> <li>Drupal Canvas</li> <li>Display Builder</li> <li><a href="https://github.com/voidlabs/mosaico">Mosaico</a></li> <li>EmailBuilder.js</li> <li><a href="https://github.com/GrapesJS/grapesjs">GrapesJS</a></li> <li><a href="https://github.com/zalify/easy-email-editor">easy-email-editor</a></li> <li><a href="https://github.com/unlayer/react-email-editor">React Email Editor</a></li> </ul> <p><strong>5. A Scheduling plugin type.</strong> Each plugin decides when a<br> campaign sends, and resolves to a concrete send time. Anticipated<br> implementations:</p> <ul> <li>Immediately</li> <li>At a selected date and time</li> </ul> <h2>Scope</h2> <p><strong>In scope:</strong> both entity types and their bundles, the three<br> plugin managers with their interfaces and base classes, admin routes and<br> permissions for CRUD, and enough of a default implementation of each plugin type<br> to prove the interfaces are usable.</p> <p><strong>Out of scope</strong> &mdash; each becomes its own issue:</p> <ul> <li>Actual message delivery. Sending is delegated to channel-specific<br> integrations; this module models the campaign, it does not transmit it.</li> <li>Open/click tracking implementation. This issue stores the two settings<br> flags only.</li> <li>A/B testing, variant splits and winner selection.</li> <li>Multi-step automations, triggers and conditions. The campaign/message split<br> is what makes these possible later; none of the sequencing is built here.</li> <li>Per-recipient engagement events and campaign-level rollups.</li> <li>Every concrete Recipient, Composition and Scheduling plugin beyond the<br> reference implementations.</li> </ul> <h2>Open questions</h2> <p>These want deciding before implementation, not during:</p> <ul> <li><strong>How campaign relates to message.</strong> An entity reference field<br> on the campaign, or a parent reference on the message. Ordering matters<br> once multi-step automations arrive, so the choice should anticipate a<br> sequence rather than an unordered set.</li> <li><strong>Which side owns the shared fields.</strong> From name/email and the<br> tracking flags could sit on either entity, or on the campaign as defaults<br> that a message may override. Overrides are more flexible and more code.</li> <li><strong>Where the body actually lives.</strong> If a Composition plugin<br> authors the HTML, then plugin configuration is the source of truth and the<br> HTML field is rendered output. Whether that output is stored, cached or<br> recomputed affects revisioning and sending alike.</li> <li><strong>"Sent to" depends on the recipient source.</strong> A pattern like<br> <code>[First] [Last]</code> presumes per-recipient fields that a bare list<br> of email addresses cannot supply. The Recipient plugin interface therefore<br> has to describe what each recipient exposes, not merely yield an address.</li> <li><strong>Include/exclude modelling</strong> &mdash; two separate fields, or one<br> multi-value field with a negate flag. Also: deduplication, and whether the<br> resolved audience is snapshotted at send time or recomputed.</li> <li><strong>Scheduling scope.</strong> A campaign-level plugin covers a<br> one-time send. Multi-step automations will want per-message timing, often<br> relative to a prior step. Whether the plugin type is designed for that now<br> or widened later is a deliberate call.</li> <li><strong>Web URL</strong> &mdash; a stored field, or a route plus canonical link<br> derived from the entity.</li> <li><strong>Immutability after sending.</strong> Revisions record what changed,<br> but they do not by themselves stop a sent campaign from being edited. Worth<br> deciding whether sent entities lock, and what the revision history is<br> expected to prove.</li> </ul> <h2>Remaining tasks</h2> <ul> <li>Settle the open questions above.</li> <li>Evaluate what existing contrib already covers &mdash; Message, DANSE, Notifier &mdash;<br> and decide what this module owns versus delegates.</li> <li>Implement both entity types, their bundles, and the three plugin managers<br> and interfaces.</li> <li>Admin UI, routes, permissions.</li> <li>Kernel tests for both entity types and all three plugin managers, including<br> revision coverage; functional coverage for the admin UI.</li> </ul> <h2>API changes</h2> <p>New module; no existing API to break. This issue defines the initial public<br> surface &mdash; two entity types and three plugin interfaces with their base classes &mdash;<br> so the interfaces are worth getting right before the first tagged release.</p> <h2>Data model changes</h2> <p>Introduces the <code>campaign</code> and <code>campaign_message</code><br> revisionable content entity types, with <code>campaign_type</code> and<br> <code>campaign_message_type</code> config entities as their bundles. No upgrade<br> path is required; the project has no supported release.</p> <p>AI-Generated: Yes (Used Claude Code Opus 5 and/or Fable 5 to generate the text of this issue.)</p>