GovOPlaN/govoplan-postbox
1
0
Fork 0
Code Issues 23 Pull Requests Actions Packages Projects Releases Wiki Activity

[User Story] Deliver campaign messages to organizational function postboxes #16

New Issue
Open
opened 2026-07-28 18:59:04 +02:00 by zemion · 1 comment
zemion commented 2026-07-28 18:59:04 +02:00
Owner
Copy Link

User story

As an institution, I want campaigns and other producers to deliver a message to an institutional function in an organizational unit rather than to one person, so that every currently responsible identity can access it through their account and responsibility changes do not break the address or history.

As a user holding several functions, I want to see selected postboxes together and keep others separate, while every message retains its source postbox, organization, function, security context, and audit history.

Domain ownership

  • Organizations owns units, structures, function types, and concrete functions.
  • Identity owns identities and accounts.
  • IDM owns effective identity-to-function assignments, delegation, acting-for context, and assignment lifecycle facts.
  • Access authorizes generic Postbox actions; a function assignment does not become an RBAC role merely to open the corresponding function postbox.
  • Postbox owns templates, stable addresses, containers, messages, delivery/routing records, visibility decisions, grouping preferences, and retention.
  • Campaign owns campaign preparation and per-target delivery evidence and uses only a versioned Postbox delivery capability.

Core journey

  1. Define a reusable function type and link concrete functions to organizational units.
  2. Define a Postbox template for that function type and unit scope; resolve stable unit-specific postbox addresses lazily, including vacant functions.
  3. Assign identities/accounts to concrete functions in IDM, with effective dates and delegation where allowed.
  4. Build a Campaign whose delivery channel targets one or more function/unit postbox addresses.
  5. Preview resolved addresses, vacancies, hierarchy-copy effects, classifications, and duplicates before committing delivery.
  6. Deliver idempotently and retain per-target evidence; eligible incumbents see the message according to the assignment/access snapshot and current-access policy.
  7. Reassignment changes current access without changing the postbox address or rewriting historical evidence.

Product rules

  • Postboxes are durable institutional containers, not personal or login-bound mailboxes.
  • Unified inboxes are projections; source containers and evidence are never merged.
  • Parent visibility/copy is disabled by default and must be explicit, bounded, explainable, classification-aware, and snapshotted at delivery time.
  • Vacancy must be visible and routable without silently granting an unrelated person access.
  • Channel fallback, duplication, acknowledgement, and retry semantics are explicit and auditable.
  • Optional Files, Notifications, Mail, Portal, Campaign, Workflow, Policy, Audit, and future encryption integrations use capabilities/events rather than implementation imports.

Acceptance criteria

  • The end-to-end path works for multiple incumbents, a vacancy, reassignment, delegation, and one bounded parent-copy rule.
  • A mixed campaign can deliver through Mail and/or Postbox according to an explicit channel policy without silent fallback.
  • The recipient report distinguishes accepted delivery, readable-by-current-holder, vacant, read/acknowledged, failed, retried, and outcome-unknown states.
  • Every access and routing decision is tenant-safe and explainable from function, unit, assignment, policy, and delivery provenance.

Ordered work packages

P1 foundation and first journey

  1. Postbox module manifest and capability contracts and domain model.
  2. IDM effective assignments and lifecycle events plus Organizations hierarchy/function types.
  3. Function-bound access resolution and function-scoped templates/stable addresses.
  4. Tenant-safe APIs and idempotent delivery, producer delivery capability, and security/lifecycle tests.
  5. Navigation/admin shell, inbox, and template/binding/routing administration.
  6. Campaign delivery adapter, currently blocked on the Postbox delivery foundation.
  7. Bounded hierarchy copy and vacancy escalation.

P2 extensions

## User story As an institution, I want campaigns and other producers to deliver a message to an institutional function in an organizational unit rather than to one person, so that every currently responsible identity can access it through their account and responsibility changes do not break the address or history. As a user holding several functions, I want to see selected postboxes together and keep others separate, while every message retains its source postbox, organization, function, security context, and audit history. ## Domain ownership - Organizations owns units, structures, function types, and concrete functions. - Identity owns identities and accounts. - IDM owns effective identity-to-function assignments, delegation, acting-for context, and assignment lifecycle facts. - Access authorizes generic Postbox actions; a function assignment does not become an RBAC role merely to open the corresponding function postbox. - Postbox owns templates, stable addresses, containers, messages, delivery/routing records, visibility decisions, grouping preferences, and retention. - Campaign owns campaign preparation and per-target delivery evidence and uses only a versioned Postbox delivery capability. ## Core journey 1. Define a reusable function type and link concrete functions to organizational units. 2. Define a Postbox template for that function type and unit scope; resolve stable unit-specific postbox addresses lazily, including vacant functions. 3. Assign identities/accounts to concrete functions in IDM, with effective dates and delegation where allowed. 4. Build a Campaign whose delivery channel targets one or more function/unit postbox addresses. 5. Preview resolved addresses, vacancies, hierarchy-copy effects, classifications, and duplicates before committing delivery. 6. Deliver idempotently and retain per-target evidence; eligible incumbents see the message according to the assignment/access snapshot and current-access policy. 7. Reassignment changes current access without changing the postbox address or rewriting historical evidence. ## Product rules - Postboxes are durable institutional containers, not personal or login-bound mailboxes. - Unified inboxes are projections; source containers and evidence are never merged. - Parent visibility/copy is disabled by default and must be explicit, bounded, explainable, classification-aware, and snapshotted at delivery time. - Vacancy must be visible and routable without silently granting an unrelated person access. - Channel fallback, duplication, acknowledgement, and retry semantics are explicit and auditable. - Optional Files, Notifications, Mail, Portal, Campaign, Workflow, Policy, Audit, and future encryption integrations use capabilities/events rather than implementation imports. ## Acceptance criteria - The end-to-end path works for multiple incumbents, a vacancy, reassignment, delegation, and one bounded parent-copy rule. - A mixed campaign can deliver through Mail and/or Postbox according to an explicit channel policy without silent fallback. - The recipient report distinguishes accepted delivery, readable-by-current-holder, vacant, read/acknowledged, failed, retried, and outcome-unknown states. - Every access and routing decision is tenant-safe and explainable from function, unit, assignment, policy, and delivery provenance. <!-- codex-postbox-work-packages-2026-07-28 --> ## Ordered work packages ### P1 foundation and first journey 1. [Postbox module manifest and capability contracts](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/1) and [domain model](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/2). 2. [IDM effective assignments and lifecycle events](https://git.add-ideas.de/GovOPlaN/govoplan-idm/issues/5) plus [Organizations hierarchy/function types](https://git.add-ideas.de/GovOPlaN/govoplan-organizations/issues/5). 3. [Function-bound access resolution](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/3) and [function-scoped templates/stable addresses](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/17). 4. [Tenant-safe APIs and idempotent delivery](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/4), [producer delivery capability](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/6), and [security/lifecycle tests](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/5). 5. [Navigation/admin shell](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/10), [inbox](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/11), and [template/binding/routing administration](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/12). 6. [Campaign delivery adapter](https://git.add-ideas.de/GovOPlaN/govoplan-campaign/issues/81), currently blocked on the Postbox delivery foundation. 7. [Bounded hierarchy copy and vacancy escalation](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/18). ### P2 extensions - [Per-user unified group projections](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/19) - [Postbox notifications](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/20) - [Files integration](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/7), [Portal integration](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/8), and [Mail bridge](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/9) - [E2EE-ready envelope/key architecture](https://git.add-ideas.de/GovOPlaN/govoplan-postbox/issues/15)
zemion commented 2026-07-29 00:19:19 +02:00
Author
Owner
Copy Link

Codex State: progress

The first end-to-end institutional Postbox path now exists locally: organization/function target -> current IDM incumbency/vacancy -> stable Postbox -> idempotent delivery -> inbox/read/ack/evidence/notification. Campaign can discover and call the optional delivery contract. Mixed-channel Campaign schema/reporting and bounded hierarchy copy remain open in #23/#81 and #18.

## Codex State: progress The first end-to-end institutional Postbox path now exists locally: organization/function target -> current IDM incumbency/vacancy -> stable Postbox -> idempotent delivery -> inbox/read/ack/evidence/notification. Campaign can discover and call the optional delivery contract. Mixed-channel Campaign schema/reporting and bounded hierarchy copy remain open in #23/#81 and #18.
zemion added
status
in-progress
 and removed
status
ready
 labels 2026-07-29 00:20:19 +02:00
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
area/api
HTTP API contracts, routers, schemas, or API smoke behavior.
area/auth
Authentication, sessions, access bootstrap, or login behavior.
area/db
Database sessions, models, transactions, or persistence primitives.
area/devex
Local developer workflow, scripts, tests, tooling, or release helpers.
area/docs
Durable documentation and project guidance.
area/governance
Governance policy, audit, privacy, retention, or compliance behavior.
area/marketing
Public website, product messaging, publication copy, or legal page content.
area/migrations
Alembic migrations, schema bootstrap, or persistence evolution.
area/module-system
Module discovery, manifests, capabilities, routing, or optional integrations.
area/rbac
Permissions, roles, delegation, or authorization policy.
area/release
Versioning, release locks, tags, packaging, or dependency pins.
area/security
Security posture, static analysis, supply-chain hardening, or vulnerability remediation.
area/tenancy
Tenant boundaries, provisioning, or tenant-scoped data behavior.
area/webui
Shared WebUI shell, frontend components, routing, or frontend tests.
audit/complexity
Complexity finding from Radon, Xenon, or equivalent maintainability scans.
audit/duplication
Duplicated-code finding from jscpd or equivalent similarity scans.
audit/false-positive
Audit finding reviewed as a narrow false positive or acceptable risk.
audit/needs-design
Audit finding that needs an architectural or product decision before implementation.
audit/quick-fix
Audit finding that appears narrow and directly fixable.
audit/structural
Audit finding that needs design, refactoring, or behavior review.
codex/needs-human
Needs an explicit human decision before Codex should implement.
codex/ready
Suitable for Codex to pick up with the existing issue context.
module/access
GovOPlaN access, identity, authentication, RBAC, and administration behavior.
module/addresses
GovOPlaN Addresses module behavior or integration.
module/admin
GovOPlaN Admin module behavior or integration.
module/appointments
GovOPlaN Appointments module behavior or integration.
module/audit
GovOPlaN Audit module behavior or integration.
module/calendar
GovOPlaN Calendar module behavior or integration.
module/campaign
GovOPlaN campaign module behavior or integration.
module/cases
GovOPlaN Cases module behavior or integration.
module/connectors
GovOPlaN Connectors module behavior or integration.
module/core
GovOPlaN core runner, shared primitives, shell, or extension points.
module/dataflow
GovOPlaN Dataflow module behavior or integration.
module/datasources
GovOPlaN governed datasource contracts, catalogs, and integrations.
module/dist-lists
GovOPlaN Distribution Lists module behavior or integration.
module/dms
GovOPlaN Dms module behavior or integration.
module/erp
GovOPlaN Erp module behavior or integration.
module/evaluation
GovOPlaN Evaluation module behavior or integration.
module/files
GovOPlaN files module behavior or integration.
module/fit-connect
GovOPlaN Fit Connect module behavior or integration.
module/forms
GovOPlaN Forms module behavior or integration.
module/identity
GovOPlaN Identity module behavior or integration.
module/identity-trust
GovOPlaN Identity Trust module behavior or integration.
module/idm
GovOPlaN Idm module behavior or integration.
module/ledger
GovOPlaN Ledger module behavior or integration.
module/mail
GovOPlaN mail module behavior or integration.
module/notifications
GovOPlaN Notifications module behavior or integration.
module/ops
GovOPlaN Ops module behavior or integration.
module/organizations
GovOPlaN Organizations module behavior or integration.
module/payments
GovOPlaN Payments module behavior or integration.
module/permits
GovOPlaN Permits module behavior or integration.
module/policy
GovOPlaN Policy module behavior or integration.
module/poll
GovOPlaN Poll module behavior or integration.
module/portal
GovOPlaN Portal module behavior or integration.
module/postbox
GovOPlaN Postbox module behavior or integration.
module/reporting
GovOPlaN Reporting module behavior or integration.
module/risk-compliance
GovOPlaN Risk Compliance module behavior or integration.
module/scheduling
GovOPlaN Scheduling module behavior or integration.
module/search
GovOPlaN Search module behavior or integration.
module/tasks
GovOPlaN Tasks module behavior or integration.
module/templates
GovOPlaN Templates module behavior or integration.
module/tenancy
GovOPlaN Tenancy module behavior or integration.
module/views
GovOPlaN governed task views, interface projections, and workflow view integration.
module/workflow
GovOPlaN Workflow module behavior or integration.
module/xoev
GovOPlaN Xoev module behavior or integration.
module/xrechnung
GovOPlaN Xrechnung module behavior or integration.
module/xta-osci
GovOPlaN Xta Osci module behavior or integration.
priority
p0
Immediate stop-the-line priority.
priority
p1
High priority for the next focused work window.
priority
p2
Normal planned priority.
priority
p3
Low priority or opportunistic cleanup.
source/backlog-import
Imported from markdown backlog, roadmap, plan, or TODO files.
source/security-audit
Created from a structured security or code-quality audit report.
source/todo-scan
Imported from inline TODO/FIXME/HACK markers by the Gitea TODO importer.
status
blocked
Cannot progress without a decision, dependency, credential, or external change.
status
in-progress
Currently being worked.
status
needs-info
Needs clarifying input before implementation can proceed safely.
status
ready
Ready for implementation.
status
triage
Needs review, ownership, priority, or acceptance criteria.
type
bug
A reproducible defect, regression, or incorrect behavior.
type
debt
Cleanup, refactoring, risk reduction, or deferred engineering work.
type
docs
Documentation, process, or developer workflow work.
type
feature
New user-visible behavior or platform capability.
type
task
Implementation, maintenance, migration, or operational work.
type
user-story
End-to-end user journey or real-world process story used to steer product slices.
No Label
area/api
area/db
area/governance
area/security
area/webui
codex/ready
module/access
module/campaign
module/idm
module/organizations
module/postbox
priority
p1
status
in-progress
type
user-story
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
zemion
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-postbox#16
No description provided.
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?