46 lines
2.6 KiB
Markdown
46 lines
2.6 KiB
Markdown
# GovOPlaN Campaign Examples
|
|
|
|
These examples are the maintained scenario catalogue for campaign release
|
|
checks. They are intentionally small and credential-free. Add concrete fixture
|
|
files next to this README only when they can be validated by the current
|
|
campaign schema and do not require production data.
|
|
|
|
## Scenarios
|
|
|
|
| Scenario | Required Modules | Release Check |
|
|
| --- | --- | --- |
|
|
| `simple-announcement` | core, access, campaigns | Validate and build one active recipient without attachments. |
|
|
| `addressing-matrix` | core, access, campaigns | Exercise To, CC, BCC, Reply-To, bounce, and disposition-notification fields. |
|
|
| `global-attachment` | core, access, campaigns; optional files | Build one deterministic attachment and verify evidence. |
|
|
| `recipient-attachment-rules` | core, access, campaigns; optional files | Match recipient-specific attachment rules and verify per-recipient evidence. |
|
|
| `zip-protected` | core, access, campaigns | Build password-protected AES ZIP output and verify password-source metadata. |
|
|
| `mail-profile-send` | core, access, campaigns, mail | Select a reusable mail profile and send through the GreenMail test bed. |
|
|
| `inline-mail-settings` | core, access, campaigns, mail | Use campaign-local SMTP/IMAP settings only when policy allows it. |
|
|
| `warnings-review` | core, access, campaigns | Require explicit review before queueing jobs with warnings. |
|
|
| `blocked-send` | core, access, campaigns | Confirm blocked recipients or missing attachments cannot be queued. |
|
|
| `mock-delivery` | core, access, campaigns, mail with dev capability | Capture messages in the development mailbox. |
|
|
| `greenmail-delivery` | core, access, campaigns, mail | Send no-attachment, normal attachment, and ZIP attachment variants through `dev/mail-testbed`. |
|
|
|
|
## Fixture Rules
|
|
|
|
- Do not commit real recipients, mail credentials, or production attachment
|
|
names.
|
|
- Keep attachments deterministic and small.
|
|
- Store secrets as placeholders, saved-credential references, or local `.env`
|
|
values consumed by the test bed.
|
|
- Declare optional module requirements in fixture metadata.
|
|
- Fixtures must not import files or mail modules directly; optional behavior is
|
|
discovered through core module metadata and capabilities.
|
|
|
|
## Validation Flow
|
|
|
|
Before a release tag:
|
|
|
|
1. Run module permutation startup checks from core.
|
|
2. Validate every committed example fixture against the current campaign schema.
|
|
3. Build exact messages for each fixture.
|
|
4. Run the mock-delivery example when the dev mailbox capability is enabled.
|
|
5. Run `dev/mail-testbed/run_transport_smoke.py`.
|
|
6. Execute the delivery checklist in
|
|
`docs/EXAMPLE_CAMPAIGNS_AND_RELEASE_CHECKLIST.md`.
|