chore: sync GovOPlaN module split state

This commit is contained in:
2026-07-10 12:51:23 +02:00
parent 6c886fe38f
commit 7c666e61f2

View File

@@ -1,8 +1,15 @@
# GovOPlaN Scheduling # GovOPlaN Scheduling
GovOPlaN Scheduling owns meeting scheduling and `Terminfindung`: finding suitable times across people, resources, calendars, constraints, and scheduling polls. GovOPlaN Scheduling owns meeting scheduling and `Terminfindung`: finding
suitable times across people, resources, calendars, constraints, and scheduling
polls.
This repository is currently a tag-only scaffold. It should gain package metadata and module manifests only after the first backend or WebUI slice is designed. This repository is currently a tag-only scaffold. It should gain package
metadata, a backend manifest, and a WebUI package together when the first
implementation slice is designed.
The core boundary decision register is in
`/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.
## Scope ## Scope
@@ -14,6 +21,7 @@ Scheduling owns:
- candidate-slot ranking and conflict explanation - candidate-slot ranking and conflict explanation
- scheduling state, reminders, and decision handoff - scheduling state, reminders, and decision handoff
- optional links to external calendar/groupware systems through capabilities - optional links to external calendar/groupware systems through capabilities
- organizer permissions and poll administration semantics
Scheduling does not own: Scheduling does not own:
@@ -22,6 +30,40 @@ Scheduling does not own:
- tasks, case work, approvals, and generic workflow state; those belong in `govoplan-tasks`, `govoplan-cases`, and `govoplan-workflow` - tasks, case work, approvals, and generic workflow state; those belong in `govoplan-tasks`, `govoplan-cases`, and `govoplan-workflow`
- mail delivery or notifications; those belong in `govoplan-mail` and `govoplan-notifications` - mail delivery or notifications; those belong in `govoplan-mail` and `govoplan-notifications`
## Poll Audience Decision
Scheduling polls should support both internal and external/public
participation, but the first implementation may start internal-only.
- Internal polls use Access/IDM identities, groups, permissions, and calendar
free/busy capability lookups.
- External/public polls use signed participation links through Portal, minimal
participant identity, and explicit retention/privacy settings.
- Mixed polls are allowed only when the organizer has permission to invite
external participants and the poll explains which participant data is visible.
## Privacy, Retention, And Audit
Participant availability is sensitive operational data. Scheduling must record:
- poll creator, tenant, organizer, invited participants, and access scope
- what each participant can see about other participants
- retention deadline for availability responses and poll links
- audit events for poll creation, invite send, response update, decision,
cancellation, and handoff
- trace IDs for mail/notification/portal handoff
Availability responses should be removable or redacted after the poll decision
unless a configured process requires longer evidence retention.
## Candidate Capabilities
- `scheduling.polls`
- `scheduling.availabilityCollector`
- `scheduling.candidateSlots`
- `scheduling.decisionHandoff`
- `scheduling.portalParticipation`
## Expected Integrations ## Expected Integrations
- `govoplan-calendar`: availability, calendars, resources, rooms, recurrence, Open-Xchange/calendar adapters - `govoplan-calendar`: availability, calendars, resources, rooms, recurrence, Open-Xchange/calendar adapters
@@ -31,13 +73,15 @@ Scheduling does not own:
- `govoplan-portal`: external participant scheduling flows - `govoplan-portal`: external participant scheduling flows
- `govoplan-workflow` and `govoplan-tasks`: follow-up work after a time is selected - `govoplan-workflow` and `govoplan-tasks`: follow-up work after a time is selected
## Initial Backlog ## First Package Scaffold Decision
The active backlog lives in Gitea issues. Start with: The first scaffold should include both backend and WebUI package metadata once
implementation starts:
- define the scheduling module boundary - backend manifest, permissions, DTOs, and APIs for internal polls
- decide whether scheduling polls are internal-only, external/public, or both - WebUI route contribution for poll creation and response collection
- define the relationship between scheduling proposals and calendar events - capability contracts for calendar free/busy, access/IDM lookup,
- define privacy and retention rules for participant availability mail/notification sending, portal participation links, appointment handoff,
- define capability contracts with calendar, access, IDM, mail, notifications, portal, and appointments and workflow/task follow-up
The active backlog lives in Gitea issues.