marcandClaude Opus 5
f71ab710e1
Bisher konnte ein CalDAV-Client Termine verwalten, aber keine Kalender:
MKCALENDAR -> 405 anlegen
PROPPATCH -> 501 umbenennen, umfaerben
DELETE -> 404 loeschen
go-webdav deckt davon nur MKCOL ab, und selbst da verwarf unser Backend
die vom Client gewaehlte Adresse. Alle drei Verben faengt der Handler
jetzt vorher ab (collections.go).
Der Kern steckt aber nicht in den Verben, sondern in der Adresse: Bei
MKCALENDAR sucht *der Client* aus, wo der Kalender liegen soll
("…/calendars/max/arbeit/"). Unsere Kalender lagen bisher zwingend unter
ihrer UUID -- der Client haette angelegt und auf seine eigene Adresse
sofort ein 404 bekommen.
Deshalb Migration 23 mit einer Spalte path_segment: gesetzt = die
gewaehlte Adresse, NULL = es gilt weiterhin die UUID. Bestehende
Kalender bleiben damit unter genau der Adresse erreichbar, unter der die
eingerichteten Geraete sie kennen -- ein Wechsel haette jedes Telefon
dazu gebracht, seine Termine fuer geloescht zu halten. Aufgeloest wird
beides in einer Abfrage (GetCalendarByRef), die gewaehlte Adresse hat
Vorrang.
PROPPATCH antwortet mit einem Status je Eigenschaft, auch wenn alles
geklappt hat: Es kann teilweise gelingen, und ein nacktes 200
verschwiege, welcher Teil angekommen ist. Was wir nicht aendern koennen,
bekommt 403 statt stillem Schlucken -- ein Client, der seine Aenderung
fuer angekommen haelt, ist schlimmer dran als einer mit klarer Absage.
Ebenso eine unlesbare Farbe: absagen statt raten.
DELETE auf eine Sammlung loescht den Kalender mitsamt allen Terminen --
das ist in WebDAV seine Bedeutung.
CalDAV-Selbsttest von 45 auf 62 Pruefungen: anlegen, unter der
gewaehlten Adresse erreichbar, Farbe aus dem MKCALENDAR uebernommen,
Termin darin ablegen und abrufen, zweites Anlegen auf dieselbe Adresse
405, umbenennen und umfaerben mit Status je Eigenschaft, loeschen, danach
404 -- und dasselbe noch einmal ueber MKCOL, das Verb, das DAVx5 nimmt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
16 lines
855 B
SQL
16 lines
855 B
SQL
-- Bei MKCALENDAR sucht der **Client** die Adresse des neuen Kalenders aus
|
|
-- ("…/calendars/max/arbeit/"). Unsere Kalender liegen sonst unter ihrer
|
|
-- UUID. Ohne diese Spalte müsste der Server die gewählte Adresse verwerfen
|
|
-- und der Client bekäme auf seine eigene Adresse ein 404.
|
|
--
|
|
-- NULL heißt: keine gewählte Adresse, es gilt weiterhin die UUID. Alle
|
|
-- bestehenden Kalender bleiben damit unter genau der Adresse erreichbar,
|
|
-- unter der die eingerichteten Geräte sie schon kennen.
|
|
ALTER TABLE cal_calendars ADD COLUMN IF NOT EXISTS path_segment TEXT;
|
|
|
|
-- Teilweiser Index: Zwei Kalender desselben Kontos dürfen nicht dieselbe
|
|
-- Adresse haben, aber beliebig viele dürfen gar keine haben.
|
|
CREATE UNIQUE INDEX IF NOT EXISTS cal_calendars_owner_path_segment
|
|
ON cal_calendars (owner_id, path_segment)
|
|
WHERE path_segment IS NOT NULL;
|