connor
fd298f4977
Every one of these calls has existed in the typed client since M9 and M10 and had nothing wired to it: create, delete and update for calendars, subscribe, update and unsubscribe for feeds. The only field the interface ever sent was `visible`, from the checkbox. So a person could see the calendars on their server and hide them, and could not make one, rename one, recolour one, reorder them, or subscribe to anything at all -- the "Subscribed" section did not even draw unless a feed was already in the database, which no interface could put there. M14 was scoped as "calendar list, visibility toggles" and nothing after it picked up the rest. It goes next to the list rather than into Settings. The sidebar already is the list of sources; Settings is about the person reading them. A calendar's name and colour are neither -- they belong to the calendar, they are written to the CalDAV server, and every other client sees them. That distinction needed one thing from the API. `color_source` was already reported so the interface could offer "use the calendar's own colour", but the colour itself was only ever sent after the override was applied, so an editor had no way to know what the calendar's own colour was. One control for both would have written somebody's private override onto the shared calendar the first time they saved anything. `CalendarView` now carries `own_color` beside `color`, and the editor shows them as the two different things they are. Reordering sends only the rows that actually move. Each one is a PATCH and a round trip to the CalDAV server, and "no position at all" is a different state from "position 0" -- so the first move on a fresh account writes every row and every move after it writes two. The arithmetic for that is pure and tested, as is turning a CalDAV colour into something a colour input will accept: Apple's `calendar-color` is `#RRGGBB` or `#RRGGBBAA`, and a control with no notion of alpha reads the eight-digit form as garbage and silently shows black. Deleting a calendar destroys everything in it and there is no undo underneath, so the menu item leads into the editor with its confirmation already showing rather than doing it from the menu. The menu offers what exists: a calendar at the top of the list is not offered "Move up". The browser checks in `shoot.mjs` cover the whole round trip against a real server -- made, coloured, renamed, deleted -- and that a link which cannot work is refused before it costs a request. They cannot run yet: the file stops at its all-day overflow assertion, because `seed.py` hard-codes the week of 2026-08-24 and that week has now passed. That is a separate problem and older than this change.