51 lines
3.3 KiB
Markdown
51 lines
3.3 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`](simple-announcement/campaign.json) | core, access, campaigns | Validate and build one active recipient without attachments while Mail and Files are absent. |
|
|
| `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. |
|
|
| `legacy-inline-mail-rejected` | core, access, campaigns, mail | Confirm legacy campaign-local SMTP/IMAP data fails closed and requires explicit profile migration. |
|
|
| `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`](greenmail-delivery/campaign.json) | core, access, audit, campaigns, mail | Run a credential-free Campaign through a Mail-owned profile, GreenMail SMTP/IMAP, report/audit checks, repeat-send protection, and bounded failure drills. |
|
|
|
|
## Fixture Rules
|
|
|
|
- Do not commit real recipients, mail credentials, or production attachment
|
|
names.
|
|
- Keep attachments deterministic and small.
|
|
- Store transport secrets only in encrypted Mail profiles or local `.env`
|
|
values consumed directly by the test bed, never in campaign JSON.
|
|
- 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. Run `python -m unittest discover -s tests -p 'test_example_campaigns.py'`
|
|
from this repository. The acceptance test copies each maintained fixture to
|
|
an unrelated temporary workspace before using Campaign's public loader,
|
|
validator, and message builder.
|
|
3. Validate every committed example fixture against the current campaign schema.
|
|
4. Build exact messages for each fixture.
|
|
5. Run the mock-delivery example when the dev mailbox capability is enabled.
|
|
6. Run `dev/mail-testbed/run_transport_smoke.py` for low-level transport and attachment variants.
|
|
7. Run `dev/mail-testbed/run_campaign_acceptance.py` for the Campaign journey and bounded evidence.
|
|
8. Execute the delivery checklist in
|
|
`docs/EXAMPLE_CAMPAIGNS_AND_RELEASE_CHECKLIST.md`.
|