Stand v0.22.0 (Juli 2026), UI seit v0.26.0 im Register «Berechtigungs-Rollen» bzw. «Freigaben» · Konzept: docs/konzept-rollen-selfservice.md · Apps apps/authorization + apps/portal · Fortsetzung von Berechtigungen & Clu-Portal
Mitglieder pflegen ihre eigenen Daten selbst — der Verein steuert pro Rolle und pro Feld, was sichtbar und was bearbeitbar ist, und ob Änderungen sofort gelten oder genehmigt werden müssen.
Für Mitglieder (Portal, «Meine Daten»):
- Die Standard-Rolle «Mitglied» darf die eigene Postadresse ändern — sofort wirksam, die definierten Empfänger erhalten eine Info-Mail (alt → neu, wer, wann). Alles andere: anzeigen + «Korrektur melden».
- Mit individuellen Rollen wird pro Feld mehr möglich: bearbeitbare Felder zeigen einen Stift und ein Inline-Formular; Felder mit offenem Antrag sind gesperrt («Änderung wartet auf Freigabe»); der Antragsteller sieht den Status (beantragt/genehmigt/abgelehnt).
- E-Mail-Änderung läuft IMMER über die volle Kette: Antrag → (Genehmigung, falls nötig) → Bestätigungs-Link an die NEUE Adresse → erst dann wird angewendet (inkl. Login-Nachzug) + Sicherheits-Info an die ALTE Adresse.
- Betrifft eine Änderung eine geteilte Haushalts-Adresse oder ein Festnetz, braucht sie immer eine Genehmigung, und alle Mitbetroffenen werden informiert.
Für Freigabe-Personen (bis v0.25 «Genehmiger» genannt):
- Portal-Inbox «📥 Aufgaben (n)» — erscheint nur, wenn es offene Aufgaben gibt. Entscheiden geht dort ODER direkt per Magic-Link aus der Mail, ohne Login. Eine Person genügt (first-wins); die anderen sehen «bereits entschieden von X». CluCore zeigt eine Hint-Kachel «n offene Anträge». (Ausnahme seit v0.25.0: Spesen-Freigaben verlangen den Entscheid eingeloggt im Portal — bei Vereinsgeld darf eine weitergeleitete Mail keine Freigabe sein; die Mail verlinkt deshalb nur auf die Aufgaben-Seite.)
Für den Vorstand (Berechtigungen-Bereich):
- Pro individueller Rolle (Register Berechtigungs-Rollen, Detail-Abschnitte): Werkzeuge 📁 Datei-Browser, 📅 Kalender, ✏️ Eigene Daten bearbeiten (Modus «nur informieren» / «Freigabe nötig»), 🧾 Spesen, 🔍 Revision — plus die Feld-Matrix: jedes Personen-Feld (eingebaute + Custom-Spalten, auch der eigenen Mitgliedschaft) auf ausgeblendet/anzeigen/bearbeitbar. Beim Anlegen helfen Vorlagen (u.a. «Selbstbedienung»).
- Vereinsweite Freigabe-Personen für Änderungen an eigenen Daten (Register Freigaben; initial: wer die Freigabe einrichtet), jederzeit anpassbar — Änderungen daran landen im Audit-Log.
¶ Warum so gebaut — und warum nicht anders
- Die Mitglied-Rolle bleibt FIX (hartkodiert: Adresse bearbeitbar, Kalender an, sonst nichts) statt editierbar. Grund: Sie wird bei der Login-Aktivierung AUTOMATISCH zugewiesen — eine editierbare Basisrolle wäre ein Datenschutz-Hebel, mit dem ein Klick versehentlich interne Custom-Spalten (Notizen!) für ALLE Mitglieder öffnet. Mehr Rechte gibt es nur über bewusst zugewiesene individuelle Rollen (User-Entscheid: «zu kompliziert, datenschutztechnisch zu unsicher»).
- Nur Self-Service (eigene Person/eigene Mitgliedschaft), keine delegierte Fremd-Bearbeitung im Portal: Fremddaten bearbeiten gehört in den CluCore mit echten Teilrechten (kommt mit dem Rollen-Editor B4) — das Portal wäre das falsche Gefäss dafür.
- Custom-Spalten sind im Portal per Default AUSGEBLENDET (eingebaute Felder: anzeigen): Custom-Spalten enthalten oft Interna; sichtbar wird nur, was eine Rolle explizit freigibt. Bei mehreren Rollen gewinnt die grosszügigste Stufe (vorhersehbar), beim Modus gewinnt «Genehmigung» (die vorsichtigere Variante).
- E-Mail-Sonderweg ohne Ausnahme — auch wenn eine Rolle das Feld «bearbeitbar» stellt: Die E-Mail ist der Login-Identifier. Ohne Besitz-Nachweis der neuen Adresse (Verifikations-Link) und Info an die alte wäre das ein Konto-Übernahme-Vektor. (Faktencheck damals: der alte CluCore-«Workflow» war nur eine Passwort-Reset-Mail, KEINE Verifikation.)
- Zwangs-Genehmigung bei geteilten Entitäten, zur Laufzeit erkannt (Adresse/Festnetz mit >1 Person): Wer die Haushaltsadresse ändert, ändert sie auch für die anderen — das darf nicht still passieren.
- Eine Genehmigung genügt (first-wins) statt Quoren: Vereins-Realität — es soll schnell gehen und niemand blockieren;
select_for_update verhindert Doppel-Entscheide. Magic-Links, weil Genehmiger selten eingeloggt sind (Tokens nur als Hash, Einmalgebrauch, 14 Tage — wie beim Einladungs-Muster).
- Fallback: keine Freigabe-Personen erfasst → alle Admins. Anträge dürfen nie ins Leere laufen.
- Die Inbox ist generisch (
InboxTask mit type + payload, Empfänger mit eigenem Token) statt spezifisch für Änderungsanträge: Spesen-Workflow und künftige Freigabe-Prozesse docken ohne Schema-Änderung an. Sie erscheint nur bei offenen Aufgaben — kein toter Menüpunkt.
- Kalender-Regel (R1): Mitglied-Rolle hat «Meine Termine» immer (wie vorher, keine Migration nötig); individuelle Rollen brauchen die Freigabe
portal.kalender. Dokumentierte Folge: Personen mit NUR individueller Rolle ohne Freigabe sehen keinen Kalender.
- Weitere Portal-Freigaben nach demselben Muster: 🧾 Spesen einreichen (
portal.spesen) und 🔍 Revision (portal.revision) — Standard-Mitglied jeweils aus, bewusst pro Rolle zuzuweisen.
- Audit: Jede angewendete Änderung landet zusätzlich im bestehenden
AuthMutationAuditLog (source portal) — gleiche Spur wie CluCore-Mutationen.
Editierbare Mitglied-Basisrolle · Fremd-Bearbeitung im Portal · Mehrfach-Genehmigungen/Quoren · frei konfigurierbare Freigabe-Personen pro Rolle (EIN vereinsweites Set genügt V1).