Betreiber-Zentralstelle, Mandanten-Design und schlankerer Einstieg

Funktions-Schalter je Mandant (app/features.php, tenant_features): der
Betreiber schaltet FAQ, Selbsteintrag, PDF, PayPal-Eingang, CSV-Import,
Mailversand, Jahresabschluss, Datenexport und eigenes Design pro Mandant
frei. Gesperrte Funktionen verschwinden aus Menue und Schaltflaechen, ihre
Seiten weisen Aufrufe und POSTs ab. Das Back-Office ist jetzt fuer
Platform-Admins im Menue verlinkt statt nur per URL erreichbar.

Eigenes Design je Mandant: Akzentfarbe und Logo in den Mandant-
Einstellungen, eingebettet ueber app/branding.php; das Logo liegt
geschuetzt in var/tenant_logos und wird nur ueber
tenant-logo-anzeigen.php an den eigenen Mandanten ausgeliefert.

Weniger Startinformationen: Startpaket neuer Mandanten auf zwei
Beispielfragen gekuerzt, Anleitung von ~1400 auf ~750 Woerter gestrafft
und um Abschnitte zu gesperrten Funktionen bereinigt.

Vorder-/Rueckseite erst bei mehr als 50 Personen (vorher schon ab 50).
Die Schwelle liegt jetzt gemeinsam in app/ledger.php und gilt auch fuer
die Vorder-/Rueckseiten-Auswahl beim Erfassen, wo sie bisher unabhaengig
von der Teamgroesse angeboten wurde.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>

docs/backoffice.md

@@ -54,15 +54,75 @@ demselben Grund wie beim Setzen).
 
 - `backoffice.php`: Übersicht aller Mandanten mit Kürzel, Status,
   Erstelldatum, Teilnehmerzahl (aktiv/gesamt) und Saldensumme.
-- `backoffice-mandant.php?tenant_id=X`: reine Leseansicht eines einzelnen
-  Mandanten – Einstellungen, Mitglieder mit Rolle, letzte 20 Buchungen,
-  letzte 20 Admin-Aktionen. Absichtlich **kein** Schreibzugriff auf
-  Mandantendaten von hier aus, um das Risiko einer versehentlichen
-  Fremdänderung auszuschließen.
+- `backoffice-mandant.php?tenant_id=X`: Ansicht eines einzelnen Mandanten
+  – Einstellungen, Mitglieder mit Rolle, letzte 20 Buchungen, letzte 20
+  Admin-Aktionen, dazu die Funktions-Schalter (siehe unten). Absichtlich
+  **kein** Schreibzugriff auf die eigentlichen Mandantendaten (Buchungen,
+  Mitglieder, Einstellungen des Kunden) von hier aus, um das Risiko einer
+  versehentlichen Fremdänderung auszuschließen.
 - `backoffice-export.php`: nutzt dieselbe `app_export_tenant_data()`-
   Funktion wie der Selbstbedienungs-Export, aber ausgelöst durch den
   Platform-Admin für einen beliebigen Mandanten.
 
+## Funktions-Schalter je Mandant
+
+Stand: 2026-08-17. Zentralstelle des Betreibers, um einzelne Funktionen
+pro Mandant freizuschalten oder zu sperren – gepflegt in
+`backoffice-mandant.php`, umgesetzt in `app/features.php` und der Tabelle
+`tenant_features` (Migration `0025_tenant_features.sql`).
+
+Schaltbar sind: FAQ-Seite, Striche selbst eintragen, Kaffeeliste als PDF,
+PayPal-Zahlungseingang, CSV-Import, Info-Mails und Erinnerungen,
+Jahresabschluss, Datenexport, eigenes Design.
+
+Design-Entscheidungen:
+
+- **Getrennt von `tenant_settings`.** Dort stellt der Kunde ein, *wie*
+  eine Funktion arbeitet; hier entscheidet der Betreiber, ob sie ihm
+  überhaupt zur Verfügung steht. Beide Prüfungen stehen nebeneinander,
+  z. B. beim Selbsteintrag: `self_entry_enabled` (Kunde) **und**
+  Feature `self_entry` (Betreiber).
+- **Ohne Zeile = freigeschaltet.** `tenant_features` hält nur die
+  Abweichungen vom Standard; ein neuer Mandant bekommt automatisch den
+  vollen Funktionsumfang, ohne dass der Betreiber etwas einschalten muss.
+  Fehlt die Tabelle (Migration noch nicht ausgerollt), bleibt ebenfalls
+  alles freigeschaltet – eine ausstehende Migration darf keine Funktion
+  sperren.
+- **Gesperrt heißt unsichtbar.** Die betroffenen Menüpunkte und
+  Schaltflächen verschwinden (`footer.php`, `kaffeeliste.php`,
+  `einzahlung.php`, `konto.php`); ein direkter Aufruf der Seite endet mit
+  einem Hinweis statt mit einem Fehler. Die POST-Verarbeitung der
+  betroffenen Seiten hängt an derselben Prüfung, eine gesperrte Funktion
+  lässt sich also auch nicht per Formular-POST auslösen.
+- Jede Änderung landet als `backoffice.features_updated` im Audit-Log des
+  betroffenen Mandanten – wie jeder andere Back-Office-Zugriff auch.
+
+Das Back-Office ist außerdem jetzt für Platform-Admins im Menü verlinkt
+(Gruppe „Betreiber" in `footer.php`); vorher war es nur über die direkte
+URL erreichbar.
+
+## Eigenes Design je Mandant
+
+Stand: 2026-08-17, hängt am Feature `branding`. Der Kunde hinterlegt in
+`mandant-einstellungen.php` eine Akzentfarbe und ein Logo:
+
+- Die Farbe (`tenant_settings.brand_color`, validiert als `#rrggbb`) wird
+  in `header.php` als kleines Stylesheet eingebettet
+  (`app/branding.php`), das die Akzentfarbe des Templates überschreibt.
+  Eine eigene CSS-Datei je Mandant wäre ein zusätzlicher Request für
+  wenige Zeilen.
+- Das Logo (`tenant_settings.brand_logo`) liegt wie das PDF-Wasserzeichen
+  in `var/tenant_logos` und ist damit **nicht** direkt per URL abrufbar –
+  sonst wäre jedes Kundenlogo unter einer ratbaren Adresse öffentlich.
+  Ausgeliefert wird es über `tenant-logo-anzeigen.php`, das ausschließlich
+  das Logo des Mandanten des angemeldeten Nutzers ausgibt.
+- Wasserzeichen (Ausdruck) und Marken-Logo (Oberfläche) sind getrennte
+  Dateien mit eigenem Namenspräfix (`logo_` bzw. `brand_`).
+- Sperrt der Betreiber `branding`, verschwindet der Abschnitt aus den
+  Einstellungen und die Oberfläche fällt aufs Standarddesign zurück. Die
+  gespeicherte Farbe bleibt erhalten und gilt nach einer erneuten
+  Freischaltung wieder.
+
 ## Verhältnis zum Selbstbedienungs-Export (`datenexport.php`)
 
 Bewusste Entscheidung: Der bestehende Selbstbedienungs-Export für