92 lines
3.8 KiB
Markdown
92 lines
3.8 KiB
Markdown
# GovOPlaN Scheduling
|
|
|
|
<!-- govoplan-repository-type:start -->
|
|
**Repository type:** module (domain).
|
|
<!-- govoplan-repository-type:end -->
|
|
|
|
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, 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
|
|
|
|
Scheduling owns:
|
|
|
|
- meeting scheduling polls and proposals
|
|
- participant availability collection
|
|
- time-window and resource constraints
|
|
- candidate-slot ranking and conflict explanation
|
|
- scheduling state, reminders, and decision handoff
|
|
- optional links to external calendar/groupware systems through capabilities
|
|
- organizer permissions and poll administration semantics
|
|
|
|
Scheduling does not own:
|
|
|
|
- calendar primitives such as events, recurrence, availability storage, resources, and calendar adapters; those belong in `govoplan-calendar`
|
|
- fixed-slot public or internal appointment booking; that belongs in `govoplan-appointments`
|
|
- 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`
|
|
|
|
## 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
|
|
|
|
- `govoplan-calendar`: availability, calendars, resources, rooms, recurrence, Open-Xchange/calendar adapters
|
|
- `govoplan-appointments`: conversion from a selected meeting time into a booked appointment where appropriate
|
|
- `govoplan-access` and `govoplan-idm`: participants, groups, directory lookup, permissions
|
|
- `govoplan-mail` and `govoplan-notifications`: invitations, reminders, confirmations
|
|
- `govoplan-portal`: external participant scheduling flows
|
|
- `govoplan-workflow` and `govoplan-tasks`: follow-up work after a time is selected
|
|
|
|
## First Package Scaffold Decision
|
|
|
|
The first scaffold should include both backend and WebUI package metadata once
|
|
implementation starts:
|
|
|
|
- backend manifest, permissions, DTOs, and APIs for internal polls
|
|
- WebUI route contribution for poll creation and response collection
|
|
- capability contracts for calendar free/busy, access/IDM lookup,
|
|
mail/notification sending, portal participation links, appointment handoff,
|
|
and workflow/task follow-up
|
|
|
|
The active backlog lives in Gitea issues.
|