[Feature] Make scheduling polls task-focused and calendar-aware #4

New Issue

zemion · 2026-07-20T17:08:11+02:00

zemion commented

2026-07-20 17:08:11 +02:00

User Need

Scheduling should present the task at hand rather than an always-visible control panel. Organizers need a clear request list and a full-page create surface; invited participants need to find and answer requests addressed to them. Calendar selection must use calendars they can actually access rather than requiring an internal ID.

Acceptance Criteria

List view has a prominent Add action and separates My scheduling requests from Scheduling requests for me.
Ordering prioritizes unanswered requests by nearest candidate date, then answered, closed, determined, and past requests; ordering is deterministic inside each group.
Create is a full-page form with stable upper-right Discard and named Save actions; unsaved state is guarded.
Target calendar uses the optional Calendar-owned calendar.picker capability and never asks users to enter an internal calendar ID. Missing/unavailable Calendar capability is explained without breaking poll-only creation.
An invited signed-in user can submit or update availability in Scheduling with the existing scheduling:availability:write scope; response state survives reload and identifies the matching participant without exposing invitation secrets.
External response remains supported through Poll invitations; the module does not require every participant to sign in.
Open, close, free/busy, holds, final event, reminder, and per-slot decision actions are shown only in valid lifecycle contexts and explain their effect/disabled reason.
UI follows shared tokens, accessible labels/tooltips, keyboard behavior, responsive layout, and translated user-facing strings.
Backend and WebUI tests cover ownership grouping/order, Calendar capability present/absent, authenticated response reconciliation, lifecycle actions, and the full-page action layout.

Action Semantics

Open: make the backing Poll accept responses and mark Scheduling as collecting.
Close: stop responses and mark the request closed.
Check free/busy: evaluate candidate slots against the selected target calendar and retain evidence.
Create holds: idempotently create tentative events for candidate slots not already holding one.
Create event: after a slot is decided, create the confirmed event and mark handoff complete.
Send reminder: enqueue one notification for each active participant.
Decide slot: select a candidate, close/decide the Poll, notify participants, and optionally create the final event.

## User Need Scheduling should present the task at hand rather than an always-visible control panel. Organizers need a clear request list and a full-page create surface; invited participants need to find and answer requests addressed to them. Calendar selection must use calendars they can actually access rather than requiring an internal ID. ## Acceptance Criteria - [ ] List view has a prominent Add action and separates `My scheduling requests` from `Scheduling requests for me`. - [ ] Ordering prioritizes unanswered requests by nearest candidate date, then answered, closed, determined, and past requests; ordering is deterministic inside each group. - [ ] Create is a full-page form with stable upper-right `Discard` and named `Save` actions; unsaved state is guarded. - [ ] Target calendar uses the optional Calendar-owned `calendar.picker` capability and never asks users to enter an internal calendar ID. Missing/unavailable Calendar capability is explained without breaking poll-only creation. - [ ] An invited signed-in user can submit or update availability in Scheduling with the existing `scheduling:availability:write` scope; response state survives reload and identifies the matching participant without exposing invitation secrets. - [ ] External response remains supported through Poll invitations; the module does not require every participant to sign in. - [ ] Open, close, free/busy, holds, final event, reminder, and per-slot decision actions are shown only in valid lifecycle contexts and explain their effect/disabled reason. - [ ] UI follows shared tokens, accessible labels/tooltips, keyboard behavior, responsive layout, and translated user-facing strings. - [ ] Backend and WebUI tests cover ownership grouping/order, Calendar capability present/absent, authenticated response reconciliation, lifecycle actions, and the full-page action layout. ## Action Semantics - **Open:** make the backing Poll accept responses and mark Scheduling as collecting. - **Close:** stop responses and mark the request closed. - **Check free/busy:** evaluate candidate slots against the selected target calendar and retain evidence. - **Create holds:** idempotently create tentative events for candidate slots not already holding one. - **Create event:** after a slot is decided, create the confirmed event and mark handoff complete. - **Send reminder:** enqueue one notification for each active participant. - **Decide slot:** select a candidate, close/decide the Poll, notify participants, and optionally create the final event.

zemion commented

2026-07-20 17:36:27 +02:00

Codex State: progress

Summary

Implemented the task-focused scheduling poll flow in local commits de7e68c, fc418e6, and 887e064.
Calendar selection uses the shared calendar.picker capability from Core 78b4afd / Calendar 68b165d; no raw ID entry or private Calendar import remains.
Added organizer/participant visibility, My/For-me/Managed worklists, requested priority order, full-page create with Discard/Save, in-module response, contextual action explanations, and server-enforced lifecycle/Calendar state guards.
Cross-channel signed-link and authenticated responses update the same Poll response; terminal retries do not duplicate decision/cancellation notifications.
Cross-repository Poll contracts and access hardening are local commits Core 6e373dc and Poll e7f3b1d/f4d5cac.

Verification

Scheduling unittest suite: 19/19 passed
Poll unittest suite: 16/16 passed
Scheduling view-model tests: 3/3 passed; UI structure and strict TypeScript passed
Calendar + Scheduling production build: 1,904 modules transformed
Calendar regression suite: 84/84 passed

Next / Blocked

Keep open until these local commits are reviewed and integrated; no push was performed.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Implemented the task-focused scheduling poll flow in local commits de7e68c, fc418e6, and 887e064. - Calendar selection uses the shared calendar.picker capability from Core 78b4afd / Calendar 68b165d; no raw ID entry or private Calendar import remains. - Added organizer/participant visibility, My/For-me/Managed worklists, requested priority order, full-page create with Discard/Save, in-module response, contextual action explanations, and server-enforced lifecycle/Calendar state guards. - Cross-channel signed-link and authenticated responses update the same Poll response; terminal retries do not duplicate decision/cancellation notifications. - Cross-repository Poll contracts and access hardening are local commits Core 6e373dc and Poll e7f3b1d/f4d5cac. ### Verification - `Scheduling unittest suite: 19/19 passed` - `Poll unittest suite: 16/16 passed` - `Scheduling view-model tests: 3/3 passed; UI structure and strict TypeScript passed` - `Calendar + Scheduling production build: 1,904 modules transformed` - `Calendar regression suite: 84/84 passed` ### Next / Blocked - Keep open until these local commits are reviewed and integrated; no push was performed. Suggested status label: `status/in-progress`

zemion commented

2026-07-22 03:47:15 +02:00

Codex State: progress

Summary

Implemented explicit signed copy/send/revoke invitation lifecycle, public response page and prefill, bounded cancellation notices, central tenant-visible people selection, atomic slot reordering, and participant revision/replacement semantics.
Removed Scheduling imports of Poll internals through governed Core capabilities; removed/replaced participants are excluded from live aggregation while Poll retains auditable response history.

Verification

Scheduling: 69 passed; Poll: 59 passed, 1 optional PostgreSQL test skipped; focused WebUI suites pass.

Next / Blocked

Publish the reviewable 0.1.11 commits and update the reviewed migration release baseline.
Generic self-enrolment links remain deferred until their abuse, identity-proofing, and participant-creation policy is agreed; personalized links are complete.

Suggested status label: status/in-progress

## Codex State: progress ### Summary - Implemented explicit signed copy/send/revoke invitation lifecycle, public response page and prefill, bounded cancellation notices, central tenant-visible people selection, atomic slot reordering, and participant revision/replacement semantics. - Removed Scheduling imports of Poll internals through governed Core capabilities; removed/replaced participants are excluded from live aggregation while Poll retains auditable response history. ### Verification - `Scheduling: 69 passed; Poll: 59 passed, 1 optional PostgreSQL test skipped; focused WebUI suites pass.` ### Next / Blocked - Publish the reviewable 0.1.11 commits and update the reviewed migration release baseline. - Generic self-enrolment links remain deferred until their abuse, identity-proofing, and participant-creation policy is agreed; personalized links are complete. Suggested status label: `status/in-progress`

zemion commented

2026-07-22 08:03:42 +02:00

Codex State: done

Summary

The task-focused, calendar-aware scheduling surface and backend contract are integrated on origin/main at v0.1.11.
Acceptance coverage includes split My/For-me worklists and ordering, full-page guarded editor, Calendar picker capability/fallback, authenticated response prefill/update, external signed responses, contextual lifecycle actions, central UI components, invitation lifecycle, privacy projections, and explicit-only delivery.
Generic public self-enrolment remains separate in scheduling#5 and is not part of this personalized-participant acceptance boundary.

Verification

74 Scheduling backend tests passed
12 Scheduling view-model tests passed
Scheduling UI structure contract passed

## Codex State: done ### Summary - The task-focused, calendar-aware scheduling surface and backend contract are integrated on origin/main at v0.1.11. - Acceptance coverage includes split My/For-me worklists and ordering, full-page guarded editor, Calendar picker capability/fallback, authenticated response prefill/update, external signed responses, contextual lifecycle actions, central UI components, invitation lifecycle, privacy projections, and explicit-only delivery. - Generic public self-enrolment remains separate in scheduling#5 and is not part of this personalized-participant acceptance boundary. ### Verification - `74 Scheduling backend tests passed` - `12 Scheduling view-model tests passed` - `Scheduling UI structure contract passed`

zemion closed this issue

2026-07-22 08:03:42 +02:00

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: GovOPlaN/govoplan-scheduling#4