# GovOPlaN Scheduling **Repository type:** module (domain). 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.