41 lines
1.6 KiB
Markdown
41 lines
1.6 KiB
Markdown
# Campaign Access Explanation Coverage
|
|
|
|
Campaign access explanations are resource-specific evidence. They inherit the
|
|
parent Campaign decision only where the child has no independent grant model,
|
|
and they must identify that inheritance explicitly.
|
|
|
|
## Implemented
|
|
|
|
- Campaign
|
|
- Campaign version
|
|
- Campaign delivery job / built message
|
|
- Computed Campaign report, identified by Campaign, version, and report kind
|
|
|
|
## Planned Slices
|
|
|
|
1. Recipient rows and imported recipient-source snapshots
|
|
2. Attachment bindings and frozen attachment resolutions
|
|
3. Validation issues, review decisions, and attachment-policy overrides
|
|
4. Delivery attempts, IMAP append attempts, Postbox attempts, and
|
|
reconciliation decisions
|
|
5. Campaign shares and ownership-transfer records
|
|
6. Import mapping profiles and import executions
|
|
7. Reusable Campaign templates and template revisions when the template
|
|
library becomes persistent
|
|
8. Export packages and protocol/report artifacts
|
|
|
|
Each child explanation must include:
|
|
|
|
- the child resource identity and current state;
|
|
- the parent Campaign and version where applicable;
|
|
- whether access is inherited, independently granted, or further restricted;
|
|
- effective owner/share/policy provenance;
|
|
- missing-module or unavailable-evidence reasons without leaking the hidden
|
|
object;
|
|
- a stable resource identifier suitable for audit and support links.
|
|
|
|
Delivery attempts, review decisions, reports, and exports can contain more
|
|
sensitive evidence than the Campaign summary. Their read and diagnostic/export
|
|
permissions therefore remain independently enforceable even when the parent
|
|
Campaign is readable.
|