Decide campaign sub-object resource access explanation scope #50

New Issue

2026-07-11T00:30:09+02:00

zemion commented

2026-07-11 00:30:09 +02:00

Decision needed

The platform resource-access explanation endpoint can now explain a campaign resource itself. We still need to decide which campaign sub-objects should become first-class explainable resources.

Candidate resource types:

campaign versions
recipient rows and recipient data entries
attachment rules and managed attachment bindings
send/review jobs and delivery outcomes
audit log entries and reports
template/data sections inside a campaign workspace

Acceptance criteria

Decide the initial supported campaign sub-object resource types.
Define stable resource identifiers for each accepted type.
Define which provenance sources can grant or constrain access for each type.
Document unsupported sub-objects explicitly so the current campaign-level explanation remains clear.

Context

This follows the resource-access explanation rollout for Files and Campaign. The initial implementation intentionally covers the campaign ownership/sharing object first and leaves finer-grained campaign objects behind this decision.

## Decision needed The platform resource-access explanation endpoint can now explain a `campaign` resource itself. We still need to decide which campaign sub-objects should become first-class explainable resources. Candidate resource types: - campaign versions - recipient rows and recipient data entries - attachment rules and managed attachment bindings - send/review jobs and delivery outcomes - audit log entries and reports - template/data sections inside a campaign workspace ## Acceptance criteria - Decide the initial supported campaign sub-object resource types. - Define stable resource identifiers for each accepted type. - Define which provenance sources can grant or constrain access for each type. - Document unsupported sub-objects explicitly so the current `campaign`-level explanation remains clear. ## Context This follows the resource-access explanation rollout for Files and Campaign. The initial implementation intentionally covers the campaign ownership/sharing object first and leaves finer-grained campaign objects behind this decision.

zemion added the area/security codex/needs-human module/campaign

labels 2026-07-29 14:15:09 +02:00

zemion commented

2026-07-30 14:37:27 +02:00

Product decision: initial scope accepted

Implement first-class access explanations for:

campaign_version, identified by the persistent version UUID;
campaign_delivery_job, identified by the persistent job UUID, including its built-message and delivery-attempt consequences;
campaign_report, stably identified by campaign, version, and report kind until reports become persisted artifacts.

Each explanation composes the parent Campaign ownership/share decision with object-specific permissions, version state, Policy provenance, and optional Files/Mail/Postbox constraints. Unsupported subobjects continue to explain through the nearest supported parent and must say so explicitly.

Recipient rows, built-message artifacts, attachment bindings, review/override decisions, import batches, and reusable templates are candidates for later slices. Workspace sections and individual configuration fields should not become independent resources unless they gain genuinely independent authorization.

## Product decision: initial scope accepted Implement first-class access explanations for: 1. `campaign_version`, identified by the persistent version UUID; 2. `campaign_delivery_job`, identified by the persistent job UUID, including its built-message and delivery-attempt consequences; 3. `campaign_report`, stably identified by campaign, version, and report kind until reports become persisted artifacts. Each explanation composes the parent Campaign ownership/share decision with object-specific permissions, version state, Policy provenance, and optional Files/Mail/Postbox constraints. Unsupported subobjects continue to explain through the nearest supported parent and must say so explicitly. Recipient rows, built-message artifacts, attachment bindings, review/override decisions, import batches, and reusable templates are candidates for later slices. Workspace sections and individual configuration fields should not become independent resources unless they gain genuinely independent authorization.

zemion added

status

ready

codex/ready and removed

status

needs-info

codex/needs-human labels 2026-07-30 14:37:57 +02:00

zemion referenced this issue

2026-07-30 17:34:15 +02:00

[Security] Explain recipient, attachment, and review sub-object access #85

zemion referenced this issue

2026-07-30 17:34:16 +02:00

[Security] Explain delivery evidence and reconciliation sub-object access #86

zemion referenced this issue

2026-07-30 17:34:16 +02:00

[Security] Explain campaign governance, import, template, and export sub-objects #87

zemion commented

2026-07-30 17:46:45 +02:00

Decision and initial implementation completed in 5f75035.

First-class explanations now cover Campaign versions, immutable delivery jobs/built messages, and computed reports using stable identifiers and explicit parent-Campaign provenance. The complete supported/planned matrix is recorded in docs/ACCESS_EXPLANATION_COVERAGE.md.

The remaining full-list slices are intentionally tracked as bounded follow-ups:

#85 recipient/source, attachment, validation, review and override resources
#86 delivery attempts, receipts and reconciliation evidence
#87 governance, imports, reusable templates and exported artifacts

This closes the decision issue without implying those child slices are already implemented. Focused access tests and the complete Campaign suite pass.

Decision and initial implementation completed in `5f75035`. First-class explanations now cover Campaign versions, immutable delivery jobs/built messages, and computed reports using stable identifiers and explicit parent-Campaign provenance. The complete supported/planned matrix is recorded in `docs/ACCESS_EXPLANATION_COVERAGE.md`. The remaining full-list slices are intentionally tracked as bounded follow-ups: - #85 recipient/source, attachment, validation, review and override resources - #86 delivery attempts, receipts and reconciliation evidence - #87 governance, imports, reusable templates and exported artifacts This closes the decision issue without implying those child slices are already implemented. Focused access tests and the complete Campaign suite pass.

zemion closed this issue

2026-07-30 17:46:45 +02:00

zemion commented

2026-07-30 21:48:55 +02:00

Codex State: note

Summary

Decision confirmed: apply independent access explanations to the full campaign sub-object inventory, delivered incrementally.
Initial priority remains versions, delivery jobs, and reports; recipients, attachments, review state, approvals, imports, templates, exports, governance, and evidence/reconciliation remain explicit follow-up slices.

## Codex State: note ### Summary - Decision confirmed: apply independent access explanations to the full campaign sub-object inventory, delivered incrementally. - Initial priority remains versions, delivery jobs, and reports; recipients, attachments, review state, approvals, imports, templates, exports, governance, and evidence/reconciliation remain explicit follow-up slices.

zemion commented

2026-07-30 21:49:47 +02:00

Codex State: note

Summary

Decision confirmed: apply independent access explanations to the full campaign sub-object inventory, delivered incrementally. Initial priority remains versions, delivery jobs, and reports; recipients, attachments, review state, approvals, imports, templates, exports, governance, and evidence/reconciliation remain explicit follow-up slices.

## Codex State: note ### Summary - Decision confirmed: apply independent access explanations to the full campaign sub-object inventory, delivered incrementally. Initial priority remains versions, delivery jobs, and reports; recipients, attachments, review state, approvals, imports, templates, exports, governance, and evidence/reconciliation remain explicit follow-up slices.

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-campaign#50