121 lines
5.5 KiB
Markdown
121 lines
5.5 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 initialized as a discoverable module seed. It exposes the
|
|
module manifest, permission surface, role templates, and documentation metadata
|
|
before runtime APIs, database models, migrations, and WebUI routes are
|
|
introduced.
|
|
|
|
The core boundary decision register is in
|
|
`/mnt/DATA/git/govoplan-core/docs/MODULE_ARCHITECTURE.md`.
|
|
|
|
## Scope
|
|
|
|
Scheduling owns:
|
|
|
|
- meeting scheduling polls and proposals built on `govoplan-poll`
|
|
- 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`
|
|
|
|
## Manifest Dependency Decision
|
|
|
|
The Scheduling manifest declares `poll` as a required dependency because
|
|
availability collection and option/date poll primitives belong in
|
|
`govoplan-poll`.
|
|
|
|
Scheduling should model each meeting-finding flow as a poll-backed workflow:
|
|
Poll owns candidate options, signed participation links, responses, visibility,
|
|
and result aggregation. Scheduling stores the scheduling-specific context and
|
|
uses Poll context fields to point back to its request or proposal resource.
|
|
Typical workflow steps are collect availability, rank candidates, decide, notify
|
|
participants, and hand off to Calendar or Appointments.
|
|
|
|
The manifest declares `access` and `evaluation` as optional dependencies.
|
|
Scheduling may use Access for identity, groups, and permissions, and may trigger
|
|
post-event or post-appointment feedback through Evaluation. It must not require
|
|
either module just to find a meeting time.
|
|
|
|
## Expected Integrations
|
|
|
|
- `govoplan-poll`: required availability matrix and lightweight poll primitives
|
|
- `govoplan-evaluation`: optional post-event, post-appointment, or process feedback
|
|
- `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`: optional 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 backend implementation slice adds runtime APIs and storage around
|
|
poll-backed scheduling requests:
|
|
|
|
- scheduling request, candidate slot, and participant storage
|
|
- automatic `govoplan-poll` availability poll creation
|
|
- signed poll invitations for internal or external participants
|
|
- request lifecycle APIs: draft, collecting, closed, decided, handed off, cancelled
|
|
- result summaries sourced from Poll response aggregation
|
|
- optional Calendar free/busy checks, tentative holds, and final event creation
|
|
- notification outbox jobs for invitations, reminders, decisions, and cancellations
|
|
- a first Scheduling WebUI package with request creation, slot matrix, Calendar
|
|
actions, decisions, and notification-job creation
|
|
|
|
The next slices should add real notification delivery workers, richer public
|
|
participant pages, Calendar hold cleanup after decision, and advanced scoring
|
|
constraints such as required participants and quorum rules.
|
|
|
|
The active backlog lives in Gitea issues.
|