Make birthdays calendar color configurable and expose it via CalDAV

- Add a per-user birthday_calendars table (color, cascade-deletes with
  the user) and GetBirthdayCalendarColor/SetBirthdayCalendarColor in
  internal/db, plus a reservedCalendarNames guard ("birthdays") in
  CreateCalendarWithColor so no real calendar can collide with the
  synthetic one, whether created via the web UI, nidusctl, or CalDAV
  MKCALENDAR.
- Add a "Birthdays" virtual resource card to the dashboard (color
  picker only, no delete/share controls) backed by a new
  ResourceCard.Virtual flag and POST /web/resources/birthdays/color
  handler.
- Extract the birthday-parsing/generation logic shared by the web
  calendar view and CalDAV into internal/birthdays (ParseBirthday,
  Collect, OccurrenceDate, Summary) instead of duplicating it.
- Expose the Birthdays calendar over real CalDAV in
  internal/caldav/backend.go + birthdays.go: it's always listed for
  every user, generates one VEVENT per (contact, year) for a rolling
  window (current year -2..+8) with "🎂 Name (Age)" titles, is
  read-only (Put/Delete/DeleteCalendar all return 403), and its
  Apple/DAVx5 calendar-color is injected from the same per-user
  setting used by the dashboard/web view.

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
This commit is contained in:
2026-08-20 20:09:59 +02:00
co-authored by Copilot
parent cd96b365d0
commit b451f1a76e
12 changed files with 753 additions and 353 deletions
+9
View File
@@ -96,6 +96,15 @@ CREATE TABLE IF NOT EXISTS addressbook_shares (
UNIQUE (owner, addressbook_name, shared_with)
);
-- Per-user display color for the synthetic "Birthdays" calendar (computed
-- from contacts' BDAY fields, not a real user-created calendar — see
-- internal/web/calendar.go and internal/caldav/backend.go). One row per
-- user; absent means "use the built-in default color".
CREATE TABLE IF NOT EXISTS birthday_calendars (
owner TEXT PRIMARY KEY REFERENCES users (username) ON DELETE CASCADE,
color TEXT NOT NULL DEFAULT ''
);
-- Web UI login sessions. Sessions are opaque random tokens stored server
-- side (not JWTs) so they can be revoked instantly by deleting the row.
CREATE TABLE IF NOT EXISTS web_sessions (