Select what calendars to see

[Ceesaxp]

A calendar provider (Google, iCloud) may have multiple calendars defined for the user. We are fetching the default one now, but should be showing all that are defined allowing a user to select which ones to poll for events.

Additionally in the meeting template when selecting a calendar to save/create event in, we should allow choosing between them.

[Ceesaxp]

Spec: Multi-Calendar Selection per Provider

Reference mockup: docs/mockups/03-monochrome-accent/dashboard-calendars.html

1. Problem & Current State

A connected provider (Google, iCloud, CalDAV) typically exposes multiple calendars per account (e.g. Work, Personal, Holidays, plus shared calendars). Today the model treats one provider connection as one calendar:

• calendar_connections.calendar_id (internal/models/models.go:131) stores a single provider-side calendar ID (Google's primary or a single CalDAV URL).
• CalendarService.getGoogleCalendarInfo (internal/services/calendar.go:492) only calls GET .../calendars/primary — it never lists the user's CalendarList.
• CalendarService.GetBusyTimes (internal/services/calendar.go:285) iterates every calendar_connections row for the host and asks each provider for busy times on its single stored calendar ID — there is no per-calendar filter.
• meeting_templates.calendar_id, hosts.default_calendar_id, and booking_calendar_events.calendar_id all reference calendar_connections(id) — i.e. the account, not a specific calendar within it.
• The dashboard Calendars page (templates/pages/dashboard_calendars.html) and template form (templates/pages/dashboard_template_form.html:213) render one row / one <option> per connection.

2. Target Behaviour (per mockup)

The Calendars page renders accounts (provider + identity) as parent cards, with the account's enumerated calendars listed underneath. Each child calendar has:

• a colour swatch (provider-supplied colour, overridable),
• a toggle that controls whether busy times from that calendar block availability,
• a name (provider-supplied).

In the meeting template editor, the Add Event To selector is a flat list of all writable calendars across all accounts, grouped by account (<optgroup>).

3. Data Model Changes

Introduce a new provider_calendars table; keep calendar_connections as the account-level record (OAuth tokens / CalDAV creds / sync status).

New table (migrations/0XX_add_provider_calendars.up.sql):

CREATE TABLE provider_calendars (
    id UUID PRIMARY KEY DEFAULT uuid_generate_v4(),
    connection_id UUID NOT NULL REFERENCES calendar_connections(id) ON DELETE CASCADE,
    provider_calendar_id VARCHAR(500) NOT NULL,  -- Google calendar ID or CalDAV calendar URL
    name VARCHAR(255) NOT NULL,
    color VARCHAR(7) NOT NULL DEFAULT '',         -- provider hint or user override
    is_primary BOOLEAN NOT NULL DEFAULT FALSE,    -- the provider's primary/default
    is_writable BOOLEAN NOT NULL DEFAULT TRUE,    -- can we create events here?
    poll_busy BOOLEAN NOT NULL DEFAULT TRUE,      -- include in availability checks
    last_synced_at TIMESTAMP WITH TIME ZONE,
    sync_status VARCHAR(20) NOT NULL DEFAULT 'unknown',
    sync_error TEXT,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT NOW(),
    UNIQUE (connection_id, provider_calendar_id)
);
CREATE INDEX idx_provider_calendars_connection ON provider_calendars(connection_id);

Backfill in the same migration: for every existing calendar_connections row, insert one provider_calendars row with provider_calendar_id = calendar_connections.calendar_id, name = calendar_connections.name, color = calendar_connections.color, is_primary = TRUE, is_writable = TRUE, poll_busy = TRUE. Capture the new id ↔ old id mapping in a temp table.

Foreign-key migration (same migration, after backfill):

• meeting_templates.calendar_id → repoint to provider_calendars(id) using the mapping. Drop and re-add FK with ON DELETE SET NULL.
• hosts.default_calendar_id → repoint similarly.
• booking_calendar_events.calendar_id → repoint similarly (ON DELETE CASCADE retained).

Sync-status fields move to provider_calendars (each calendar can fail independently). Drop last_synced_at, sync_status, sync_error, and color from calendar_connections in a follow-up migration once all readers are updated. (Keep them in the first migration for safety; remove in 0XX+1.)

Down migrations must reverse the FK repoint and recreate the per-connection columns.

4. Model & Repository Changes

internal/models/models.go:

• Add ProviderCalendar struct mirroring the new table.
• Remove CalendarID, Color, LastSyncedAt, SyncStatus, SyncError from CalendarConnection (after the second migration); keep Name (the account label, e.g. email) and IsDefault (the default account, used as a fallback only).

internal/repository/repository.go:

• New ProviderCalendarRepository with Create, GetByID, GetByConnectionID, GetByHostID (joined through calendar_connections), GetWritableByHostID, GetPolledByHostID, Update, UpdatePollBusy(id, host_id, bool), UpdateColor(id, host_id, hex), UpdateSyncStatus, UpsertFromProvider(connection_id, provider_calendar_id, name, color, is_primary, is_writable), Delete, DeleteMissing(connection_id, keep_ids) (for sync reconciliation).
• Update the existing CalendarConnectionRepository.GetByHostID etc. to drop the removed columns from the SELECT/UPDATE lists.

5. Provider Integration Changes

internal/services/calendar.go:

Google — replace getGoogleCalendarInfo with:

• listGoogleCalendars(ctx, conn) ([]ProviderCalendar, error) calling GET https://www.googleapis.com/calendar/v3/users/me/calendarList. Map each item to: provider_calendar_id = item.id, name = item.summaryOverride or item.summary, color = item.backgroundColor, is_primary = item.primary, is_writable = item.accessRole in {owner, writer}.
• Update getGoogleBusyTimes to accept the list of calendars to poll and pass all of them in the freeBusy request items array (one HTTP call per account, not per calendar).

CalDAV / iCloud — add a calendar-discovery step:

• listCalDAVCalendars(ctx, conn) ([]ProviderCalendar, error) performing PROPFIND Depth:1 on the user's calendar-home-set (resolved via current-user-principal → calendar-home-set lookups, standard CalDAV bootstrap). For each child collection with resourcetype containing <C:calendar>: extract displayname, calendar-color (Apple ext), and the collection href as provider_calendar_id. Treat calendar-user-privilege-set containing write privileges as is_writable = true. iCloud is the same flow against https://caldav.icloud.com.
• getCalDAVBusyTimes already takes a calendar URL — call it once per polled calendar and merge.

Connection time — ConnectGoogleCalendar and ConnectCalDAV (internal/services/calendar.go:49, :118):

1. Create the calendar_connections row (account binding only — name becomes the account email/identity).
2. Call the new list…Calendars method.
3. Upsert each into provider_calendars. Default poll_busy = TRUE for all on first connect; subsequent re-syncs preserve user choices via upsert that does not touch poll_busy / color.
4. Run DeleteMissing to drop calendars the user removed at the provider.

Background sync (internal/services/calendar_sync.go):

• Iterate provider_calendars instead of calendar_connections for busy-time refresh.
• Add a periodic (e.g. once per hour) call to re-list provider calendars per connection so newly-added Google/CalDAV calendars surface in our UI.

Availability — CalendarService.GetBusyTimes (internal/services/calendar.go:285) and its caller AvailabilityService.getSingleHostSlots (internal/services/availability.go:100):

• Replace the per-connection loop with: load provider_calendars for the host where poll_busy = TRUE, group by connection_id, and issue one provider call per connection covering all selected calendars.

Event creation — CalendarService.CreateEvent/CreateEventForHost (:327, :348):

• The argument is now a provider_calendar_id (UUID of provider_calendars). Resolve it to its connection + provider_calendar_id and call the provider. Reject if is_writable = FALSE.
• BookingService.processConfirmedBooking (internal/services/booking.go:732) and createPooledHostCalendarEvents (:790) keep their structure; only the FK semantics change. The fallback in createPooledHostCalendarEvents becomes "host's default_calendar_id (now a provider_calendars.id), else the host's primary writable calendar."

6. HTTP Handlers & Routes

internal/handlers/dashboard.go + cmd/server/main.go:

Method + Path	Handler	Purpose
GET /dashboard/calendars	Calendars	Now loads connections and their provider_calendars; passes nested structure to template.
POST /dashboard/calendars/{conn_id}/refresh-list	RefreshCalendarList (new)	Re-runs list…Calendars for that connection (UI "Refresh" button per account).
POST /dashboard/calendars/sub/{calendar_id}/poll	TogglePollBusy (new)	HTMX endpoint; body `poll_busy=on
POST /dashboard/calendars/sub/{calendar_id}/color	UpdateSubCalendarColor (replaces existing /{id}/color)	Repointed to provider_calendars.
POST /dashboard/calendars/{conn_id}/disconnect	unchanged	Cascade-deletes child provider_calendars.
POST /dashboard/calendars/{conn_id}/default	SetDefaultAccount	Still useful as a fallback selector at the account level; alternatively deprecate in favour of per-calendar default. Decision needed (see §9).

Template editor handlers (EditTemplatePage, create/update template at dashboard.go:439):

• Calendar.GetWritableCalendars(ctx, hostID) returns []ProviderCalendarWithAccount for the dropdown.
• calendar_id form value continues to be parsed but now stores a provider_calendars.id.

7. Templates / UI

templates/pages/dashboard_calendars.html:

• Outer card per CalendarConnection (account header: provider icon, account name/email, connection-level status, Refresh + Disconnect).
• Inner sub-calendars block iterating range .Calendars (the connection's provider_calendars):
  • Colour swatch (reuse color_swatch_fieldset.html, pointed at the new endpoint).
  • Calendar name + read-only badge if !is_writable.
  • HTMX toggle bound to POST /dashboard/calendars/sub/{id}/poll with hx-swap="outerHTML".
  • Per-calendar last-synced / error indicator.
• "Add Calendar" section unchanged.

templates/pages/dashboard_template_form.html:213:

• Replace flat <select> with grouped:

  <select name="calendar_id">
    <option value="">Don't write to a calendar</option>
    {{range .Data.CalendarAccounts}}
      <optgroup label="{{.Name}} ({{.Provider}})">
        {{range .WritableCalendars}}
          <option value="{{.ID}}" ...>{{.Name}}</option>
        {{end}}
      </optgroup>
    {{end}}
  </select>
  

templates/partials/color_swatch_fieldset.html: pass the calendar id (now a provider_calendars.id) and update the form action.

Per CLAUDE.md's template-rendering note: any new partial added to the rendering map in internal/handlers/handlers.go must be loaded with ParseFiles, not ParseGlob.

8. Migration / Backwards-Compatibility Notes

• The id-repoint migration must run inside a transaction; verify row counts match before swapping FKs.
• After deploy, existing templates and host defaults continue to point at "the same calendar" because each old calendar_connections.id mapped 1:1 to a new provider_calendars.id flagged is_primary.
• New sub-calendars discovered on first re-sync default to poll_busy = TRUE — this can change a host's availability surface. Acceptable per issue intent, but call out in the changelog.
• CalDAV password remains plain in calendar_connections.caldav_password (pre-existing concern, out of scope here).

9. Open Questions

1. Default-account vs default-calendar. Today hosts.default_calendar_id is a single calendar used as the pooled-host fallback. Should we keep one "default writable calendar" per host, or split into "default account + each account picks its own primary writable calendar"? Recommendation: keep single default_calendar_id repointed to provider_calendars(id), drop is_default on the connection.
2. Polling vs displaying. Mockup shows one toggle per sub-calendar. Do we also need a separate "show in agenda" toggle later, or is poll_busy the only flag for now? Recommendation: single flag now; add later if the agenda view materialises.
3. Re-list cadence. Auto-refresh of provider calendar lists — every hour, every sync, only on user action? Recommendation: on connect + on user "Refresh" click + once per day in the background sync.
4. iCloud bootstrap UX. Today the user pastes a single calendar URL. With PROPFIND-based discovery we can switch the iCloud form to just username + app-specific password and discover the principal automatically. Worth doing in this change, or keep current flow? Recommendation: switch — much friendlier — but treat as a sub-task.

10. Suggested Delivery Order

1. New provider_calendars table + backfill migration + FK repoint (no behaviour change).
2. Repository + model split.
3. listGoogleCalendars + connect-flow change (Google only).
4. GetBusyTimes rewrite + poll_busy filter.
5. Calendars dashboard UI + toggle endpoint.
6. Template editor optgroup UI.
7. CalDAV PROPFIND discovery.
8. Drop deprecated columns from calendar_connections.

Each step lands as its own PR; the schema/FK move (1) and the column drop (8) are the only risky migrations.

---

Generated by Claude Code

[Ceesaxp]

Decisions on Open Questions

Confirming resolutions from offline review (and noting the previous comment said "9 open questions" — typo, there were 4):

1. Default-account vs default-calendar — Keep a single hosts.default_calendar_id, repoint to provider_calendars(id), drop is_default on calendar_connections. ✅
2. Polling vs displaying — One poll_busy flag for now; add a separate display flag later only if an agenda view needs it. ✅
3. Re-list cadence — On connect + on user "Refresh" click + once per hour in the background sync (tighter than my draft's "once per day").
4. iCloud bootstrap UX — Switch the iCloud form to username + app-specific password and discover the principal via PROPFIND; treat as a sub-task within the CalDAV step. ✅

These supersede §9 of the spec above. Delivery order in §10 is unchanged.

---

Generated by Claude Code