2.0 KiB
Calendar interface pattern migration
Calendar uses the platform workspace pattern without changing ownership of calendar or synchronization state.
Surfaces
calendar.pageis the route-level workspace.calendar.page.sidebarcontains calendar visibility and collection actions;calendar.page.agendais its event list.calendar.page.workspacecontains continuous, month, week, workweek, and day views.calendar.event-editorowns event create, edit, occurrence/series selection, and deletion confirmation.calendar.collection-editorowns local and external collection configuration. Itscalendar.sync-status,calendar.outbox, andcalendar.migrationchildren expose synchronization state and recovery.calendar.settings.preferencesandcalendar.widget.upcomingremain composed Settings and Dashboard surfaces.
The backend and WebUI manifests publish the same identifiers and parent hierarchy so Views can filter the route and contributed surfaces consistently.
Consequences and recovery
Event and collection drafts use the shared unsaved-change guard. A write that completes but whose refresh fails is not repeated blindly by Calendar synchronization workers; durable outbox and migration state remain the source of recovery evidence. Event deletion uses the shared confirmation dialog. Collection removal and destructive remote moves keep their specialized confirmation because they must expose event counts, transfer choices, authorization text, and evidence.
Unavailable consequential actions remain visible where possible and explain the missing permission, input, active write, or migration lock. Contextual help resolves through govoplan-docs when installed and otherwise uses the hosted documentation fallback.
Optional boundaries
Calendar does not import optional Mail, Campaign, Scheduling, Notifications, Connectors, Audit, or Ops implementations. Integrations continue through declared capabilities, interfaces, and stable references. Local calendars and the Calendar route remain usable without those optional modules.