[Feature] Design print campaigns with governed templates and file incorporation #105

New Issue

2026-10-13T13:11:30+02:00

zemion commented

2026-10-13 13:11:30 +02:00

Problem and scope

Print campaigns require a deliberate content-production and distribution workflow. Reusing the current Email attachment mechanics and flat print/fallback channel options is insufficient. Print authoring remains disabled for now; this issue tracks the substantial design and implementation work.

A campaign entry can have multiple recipients with individual distribution channels. Establish how a print campaign produces recipient-specific documents and distribution batches while keeping entry content/data, recipient destinations, and output artifacts distinct.

Design work

Define governed print templates, layout/pagination, recipient addressing, publication/versioning, preview and compatibility. Templates owns rendering through optional Core capabilities; Campaign owns the frozen campaign decisions.
Define required output formats (particularly PDF), deterministic generation, page/document order, accessibility, fonts, validation, and how one entry with multiple recipients maps to output copies and batches.
Replace “attach matching files to the mail” with an explicit incorporation plan: resolve Files based on patterns/rules and incorporate them into the printed output (e.g. append PDF pages, insert images, or render supported documents). Decide supported source types, placement/order, conversion, page ranges, cover sheets and duplex constraints; distinguish incorporated content from separate enclosures.
Specify pattern scope, tenant/actor authorization, classification, missing/ambiguous/multiple matches, duplicates/overlaps, deterministic ordering, limits and failure behavior. Resolve managed versions and freeze their identity/hash evidence before review. Do not allow arbitrary server paths or silently substitute newer versions.
Define output ownership/storage/retention, provenance tying template revision, entry data, recipient route, incorporation plan and exact source versions to generated artifacts and output hashes. Preserve historical artifacts and existing evidence without presenting old behavior as the new workflow.
Define review/approval of the exact generated output, preview/download permissions, print batches and handoff/spool/export providers, postal/internal-mail address requirements, reconciliation and evidence of physical distribution. “File generated,” “print submitted,” “printed,” and “delivered” are separate states; uncertain physical effects must not be automatically replayed.
Coordinate failure handling with the separate recipient fallback hierarchy issue; do not recreate entry-wide print fallback policies.

Acceptance criteria

Agree the print-campaign domain model, workflow and module responsibilities with concrete single-entry/multiple-recipient examples.
Implement published compatible templates, preview, output validation and deterministic generation with the agreed formats and pagination.
Provide explicit file-incorporation rules based on patterns and a preflight plan showing every frozen source/version and its output placement.
Validate missing/ambiguous sources, unsupported conversion, authorization/classification, output limits, duplicate ordering and optional-module availability on the server.
Freeze template, entry/recipient data, incorporation plan, source versions and output hashes in the reviewed/approved build.
Implement governed output storage/export and physical handoff with durable idempotency, audit, separate acceptance states and safe recovery/reconciliation.
Cover rendering/ordering, multi-recipient copies, source drift, missing/ambiguous patterns, permission loss, unavailable providers, partial/unknown physical effects and historical compatibility with tests.
Update bilingual user/admin documentation and schemas/import/export; enable print authoring only after the agreed workflow is complete.

Related context

#90 implemented hybrid-channel review and printable output, but this issue defines the redesigned print-campaign workflow and different file-incorporation semantics.

Related design issue: #104

## Problem and scope Print campaigns require a deliberate content-production and distribution workflow. Reusing the current Email attachment mechanics and flat print/fallback channel options is insufficient. Print authoring remains disabled for now; this issue tracks the substantial design and implementation work. A campaign entry can have multiple recipients with individual distribution channels. Establish how a print campaign produces recipient-specific documents and distribution batches while keeping entry content/data, recipient destinations, and output artifacts distinct. ## Design work - Define governed print templates, layout/pagination, recipient addressing, publication/versioning, preview and compatibility. Templates owns rendering through optional Core capabilities; Campaign owns the frozen campaign decisions. - Define required output formats (particularly PDF), deterministic generation, page/document order, accessibility, fonts, validation, and how one entry with multiple recipients maps to output copies and batches. - Replace “attach matching files to the mail” with an explicit incorporation plan: resolve Files based on patterns/rules and incorporate them into the printed output (e.g. append PDF pages, insert images, or render supported documents). Decide supported source types, placement/order, conversion, page ranges, cover sheets and duplex constraints; distinguish incorporated content from separate enclosures. - Specify pattern scope, tenant/actor authorization, classification, missing/ambiguous/multiple matches, duplicates/overlaps, deterministic ordering, limits and failure behavior. Resolve managed versions and freeze their identity/hash evidence before review. Do not allow arbitrary server paths or silently substitute newer versions. - Define output ownership/storage/retention, provenance tying template revision, entry data, recipient route, incorporation plan and exact source versions to generated artifacts and output hashes. Preserve historical artifacts and existing evidence without presenting old behavior as the new workflow. - Define review/approval of the exact generated output, preview/download permissions, print batches and handoff/spool/export providers, postal/internal-mail address requirements, reconciliation and evidence of physical distribution. “File generated,” “print submitted,” “printed,” and “delivered” are separate states; uncertain physical effects must not be automatically replayed. - Coordinate failure handling with the separate recipient fallback hierarchy issue; do not recreate entry-wide print fallback policies. ## Acceptance criteria - [ ] Agree the print-campaign domain model, workflow and module responsibilities with concrete single-entry/multiple-recipient examples. - [ ] Implement published compatible templates, preview, output validation and deterministic generation with the agreed formats and pagination. - [ ] Provide explicit file-incorporation rules based on patterns and a preflight plan showing every frozen source/version and its output placement. - [ ] Validate missing/ambiguous sources, unsupported conversion, authorization/classification, output limits, duplicate ordering and optional-module availability on the server. - [ ] Freeze template, entry/recipient data, incorporation plan, source versions and output hashes in the reviewed/approved build. - [ ] Implement governed output storage/export and physical handoff with durable idempotency, audit, separate acceptance states and safe recovery/reconciliation. - [ ] Cover rendering/ordering, multi-recipient copies, source drift, missing/ambiguous patterns, permission loss, unavailable providers, partial/unknown physical effects and historical compatibility with tests. - [ ] Update bilingual user/admin documentation and schemas/import/export; enable print authoring only after the agreed workflow is complete. ## Related context #90 implemented hybrid-channel review and printable output, but this issue defines the redesigned print-campaign workflow and different file-incorporation semantics. Related design issue: https://git.add-ideas.de/GovOPlaN/govoplan-campaign/issues/104

zemion added the

status

triage

module/campaign codex/needs-human module/files module/templates

type

feature

area/api labels 2026-10-13 13:11:30 +02:00

zemion referenced this issue

2026-10-13 13:29:48 +02:00

[Feature] Design recipient fallback hierarchies and failure-only notifications #104

Sign in to join this conversation.