From 5808ff5ef87cffea1af70fb3128ba3f7c8a1f136 Mon Sep 17 00:00:00 2001 From: marc Date: Thu, 3 Sep 2026 21:44:34 +0200 Subject: [PATCH] =?UTF-8?q?docs(kalender):=20Plugin-Frage,=20Teamkalender?= =?UTF-8?q?=20=C3=BCber=20Gruppen,=20Oberfl=C3=A4che=20und=20Farben?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit Kein Plugin: Der Projektplan legt in Abschnitt 8 selbst fest, dass Extension-Points erst nach einem stabilen Core kommen und Kernfeatures nicht als Plugin gebaut werden. Ein Plugin-System vorzuziehen hieße, die Schnittstelle nach genau einem Nutzer zu entwerfen. Stattdessen ein eigenes Paket, in einer Zeile angeschlossen, abschaltbar – der natürliche erste Kandidat, wenn es das System einmal gibt. Teamkalender brauchen nichts Neues: acl.Access trägt bereits einen Prinzipal statt eines Eigentümers, Konto oder Gruppe. Ein Kalender, der einer Gruppe gehört, ist der Teamkalender; persönliche Freigabe bleibt die Freigabe an ein Konto mit read/write. Oberfläche festgehalten: mehrere Kalender übereinander, Sichtbarkeit per Klick auf den farbigen Haken, serverseitig je Nutzer gespeichert – samt eigener Farbe je Nutzer, die in derselben Zeile fast nichts kostet. Farben getrennt notiert: Kalenderfarbe (calendar-color, de facto überall unterstützt) und Terminfarbe (RFC 7986, Weiterreichung ans Telefon ungeprüft). Co-Authored-By: Claude Opus 5 --- kalender-plan.md | 67 ++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 67 insertions(+) diff --git a/kalender-plan.md b/kalender-plan.md index 3a1137d..5c94b98 100644 --- a/kalender-plan.md +++ b/kalender-plan.md @@ -148,6 +148,73 @@ Baïkal stehen beide darauf, das ist also das Verhalten, an das die Clients gewöhnt sind. Radicale ist zum Nachlesen gut – kurzer Code –, aber es ist nicht die Fassung, gegen die getestet wurde. +## Kein Plugin – aber ausklinkbar gebaut + +Der Projektplan legt es selbst fest (Abschnitt 8): *„ERST sauberer Core. +Extension-Points erst definieren, wenn der Core stabil ist. Kernfeatures +bleiben erstklassig, nicht als Plugin."* Ein Plugin-System zu bauen, um darauf +den Kalender zu setzen, drehte diese Reihenfolge um – und ein Kalender wäre +sein erster und einziger Nutzer, also entstünde die Schnittstelle nach genau +einem Fall. + +Stattdessen so gebaut, dass er später herauszulösen ist: + +- eigenes Paket `internal/calendar`, eigene Migrationen, eigene Routen +- angeschlossen in **einer** Zeile in `main.go` +- greift nach außen nur auf `auth` und `acl` zu, nicht in andere Pakete hinein +- abschaltbar: kein Kalender aktiv → keine Routen, kein Menüpunkt + +Damit ist er der natürliche erste Kandidat, wenn es das Plugin-System einmal +gibt – ohne dass wir es vorher erfinden. + +## Teamkalender über Gruppen + +Aether kennt bereits Gruppen samt Gruppenordnern, und `acl.Access` trägt einen +**Prinzipal** statt eines Eigentümers – ein Konto *oder* eine Gruppe +(`IsGroup`). Genau das nehmen wir: + +| Zweck | Weg | +|---|---| +| **Teamkalender** | Kalender gehört einer Gruppe. Wer in der Gruppe ist, hat ihn – ohne einzelne Freigaben. Angelegt in den Admin-Optionen, wie Gruppenordner. | +| **Persönlich teilen** | Freigabe an ein einzelnes Konto, mit Recht `read` oder `write`. In der Oberfläche ein Schalter „darf auch schreiben". | + +Beides läuft über dieselbe Prüfung wie bei Dateien: `resolveCalendar` nach dem +Vorbild von `files.resolveFile`. Kein zweites Rechtekonzept. + +## Oberfläche + +**Mehrere Kalender gleichzeitig** – das ist der Normalfall, nicht die Ausnahme. +Die Ansicht legt sie übereinander; jeder Termin trägt die Farbe seines +Kalenders. + +**Sichtbarkeit mit einem Klick**, wie in Google Kalender und der Samsung-App: +runder, in der Kalenderfarbe gefüllter Haken in der Liste. Klick = an, Klick = +aus. **Serverseitig je Nutzer gespeichert**, damit es am Rechner und am Handy +gleich aussieht – dafür eine Tabelle: + + kalender_ansicht nutzer_id, kalender_id, sichtbar, reihenfolge, farbe_eigen + +Das `farbe_eigen` ist geschenkt, wenn die Zeile ohnehin existiert: Ein geteilter +Kalender darf bei dir grün und beim anderen blau sein – so macht es Google auch. + +**Wichtig:** Diese Einstellung gilt für *unsere* Oberfläche. Was das Telefon +anzeigt, entscheiden DAVx5 und Samsung Kalender selbst; darauf haben wir keinen +Zugriff. + +## Farben + +Zwei verschiedene Dinge, die man leicht verwechselt: + +- **Farbe des Kalenders** – das, was du in der Samsung-App siehst. Im Protokoll + `calendar-color` aus Apples Namensraum. Steht in keinem RFC, ist aber + de-facto-Standard: Nextcloud, Thunderbird und DAVx5 können es. **Geht.** +- **Farbe eines einzelnen Termins** – `COLOR` aus RFC 7986. In unserer eigenen + Oberfläche jederzeit möglich; wie weit DAVx5 und Samsung Kalender das + weiterreichen, ist offen und muss am Gerät geprüft werden. + +**Emojis im Kalendernamen** sind kein Protokollthema – der Name ist Text. +„🏠 Haushalt" kommt überall an. + ## Die Notausfahrt Ein Kalender, der lautlos einen Termin verschluckt, ist schlimmer als einer,