Example Campaigns And Release Checklist

This document defines the campaign examples and release gates that should be kept working before a GovOPlaN Campaign release is tagged.

Example Campaign Set

Maintain fixtures or guided examples for these scenarios. The canonical scenario catalogue lives in examples/README.md; committed fixture files should be added under examples/ only when they validate against the current campaign schema and are safe to run in non-production environments.

simple-announcement, a credential-free campaign with one active recipient and no attachments; its automated acceptance check physically blocks Mail and Files imports, denies network connections, and validates/builds from an unrelated temporary workspace
multi-recipient message with To, CC, BCC, Reply-To, bounce, and disposition notification fields
campaign with global attachments and recipient-specific attachment rules
campaign with password-protected ZIP attachments
campaign using a reusable mail profile from the mail module
legacy inline SMTP/IMAP campaign rejected with an actionable profile-migration error and no returned transport data
campaign with validation warnings that may be sent only after explicit review
campaign with blocked recipients or attachment errors that must not be sent
mock delivery campaign that captures SMTP and IMAP append messages in the mail development mailbox
greenmail-delivery, a credential-free real-delivery Campaign materialized with a temporary Mail-owned profile by the loopback acceptance runner

Fixture Rules

Examples must not contain production recipient data or production credentials.
Attachment examples should use deterministic small files and checksums.
Mail secrets belong only to encrypted Mail profiles and must never appear in a campaign fixture, placeholder, or campaign-local secret reference.
Examples that require optional modules must declare the required modules and capabilities in their README or fixture metadata.
Examples must stay valid when files or mail modules are physically absent, with optional behavior disabled instead of import failures.

Release Gates

Before tagging a campaign release:

Review examples/README.md and update the scenario catalogue when a release adds or removes delivery behavior.
Run python -m unittest discover -s tests -p 'test_example_campaigns.py' and retain its isolated validate/build result as release evidence.
Run core module permutation tests with campaign installed both with and without files/mail.
Validate and build each maintained example campaign.
Run the mock delivery example when the mail development mailbox capability is enabled.
Run the GreenMail SMTP/IMAP smoke for a non-production real delivery path.
Run dev/mail-testbed/run_campaign_acceptance.py and retain its bounded JSON projection. It must show one SMTP acceptance, one IMAP append, no duplicate effect from a repeated ordinary send, matching Campaign report/audit state, and no resolved transport material in Campaign JSON or its execution snapshot.
Do not interpret the local failure drills as post-DATA ambiguity or worker restart proof; the evidence coverage flags must keep those gaps explicit.
Confirm reusable mail profile selection is revalidated after campaign owner transfer.
Confirm every inline SMTP/IMAP field is rejected on import/write, omitted from responses, and blocked from legacy execution until explicitly migrated.
Confirm execution snapshots store only the Mail profile reference and opaque Mail-owned transport revisions, not resolved transport material.
Confirm delivery reports include SMTP outcome, IMAP append outcome, latest error, generated EML reference, and attachment evidence.
Confirm retries cannot resend messages already accepted by SMTP unless an explicit reconciliation path allows it.

Ownership Transfer Check

Reusable user/group mail profiles are owner-context-sensitive. When campaign ownership changes, the editable current version must require profile reselection and validation before live delivery. A locked delivery-final version should not be silently rewritten.

Delivery Checklist

Use the Review & Send preflight panel and the delivery runbook together:

Validate and resolve all blocking policy/data issues.
Build exact messages.
Review warnings, generated recipients, body content, and attachment evidence.
Run mock delivery if available for the release channel.
Test the selected Mail profile against non-production infrastructure.
Send only after queue, rate limit, and append-to-Sent behavior are understood.
Reconcile failed, unknown, or pending jobs from the report/audit surfaces.

4.8 KiB Raw Blame History