1

Repo docs EXAMPLE CAMPAIGNS AND RELEASE CHECKLIST

Albrecht Degering edited this page 2026-07-09 12:34:40 +02:00

Table of Contents

• Example Campaigns And Release Checklist
• Example Campaign Set
• Fixture Rules
• Release Gates
• Ownership Transfer Check
• Delivery Checklist

Mirrored from /mnt/DATA/git/govoplan-campaign/docs/EXAMPLE_CAMPAIGNS_AND_RELEASE_CHECKLIST.md. Origin: repository. Active tasks and changing state belong in Gitea issues; this wiki page is durable project context.

---

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 with one active recipient and no attachments
• 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
• campaign using inline SMTP/IMAP settings where policy allows campaign-local settings
• 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
• real non-production delivery campaign against the GreenMail test bed

Fixture Rules

• Examples must not contain production recipient data or production credentials.
• Attachment examples should use deterministic small files and checksums.
• Secret values must be represented through saved-credential placeholders or secret references.
• 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 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.
• Confirm reusable mail profile selection is revalidated after campaign owner transfer.
• Confirm inline SMTP/IMAP settings are hidden or blocked when policy disables campaign-local mail settings.
• 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:

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