Editor:innen verwalten

Setzkasten hat zwei Rollen — Admin und Editor. Welche Person welche Rolle hat, steht in _editors.json im Content-Pfad. Die Rolle kommt nicht mehr aus dem Auth-Provider — Admins können sich auch per Google einloggen, Editoren auch per GitHub.

Rollen im Überblick

• Admin — voller Zugriff. Darf Inhalte editieren, andere Editor:innen anlegen, Lizenz aktivieren, Settings ändern, History rollbacken.
• Editor — darf nur Inhalte bearbeiten. Optional auf bestimmte Seiten beschränkt (per pages-Feld). Sieht keine Settings, keine Editor:innen-Verwaltung, keine Verlauf-/Rollback-Funktion.

Im Admin verwalten

Admins öffnen ⚙ Settings → Editor:innen. Dort lassen sich Personen hinzufügen, entfernen, zwischen Admin und Editor wechseln und Seiten-Einschränkungen setzen. Änderungen werden als Entwurf gehalten und erst beim Klick auf Speichern committet.

Schutzregeln

• Last-Admin-Schutz: Mindestens ein Admin muss erhalten bleiben — der Server lehnt Updates ab, die den letzten Admin entfernen oder demoten.
• Self-Demote-Schutz: Niemand kann sich selbst herabstufen oder entfernen — eine andere Person muss das machen.
• Duplicate-Email-Schutz: Doppelte Einträge werden case-insensitive erkannt und abgelehnt.

Datei-Format

Die Datei wird im Content-Repo (Single-Mode) bzw. Config-Repo (Multi-Mode) gepflegt. Pre-v1.3-Einträge ohne role-Feld werden als editor behandelt — bestehende _editors.json-Dateien funktionieren ohne Änderung.

// content/_editors.json
[
  {
    "email": "chefin@example.com",
    "role": "admin"
  },
  {
    "email": "redaktion@example.com",
    "role": "editor"
  },
  {
    "email": "blog-autor@example.com",
    "role": "editor",
    "pages": ["blog", "news"]
  }
]

Bootstrap (erste Anmeldung)

Solange keine _editors.json existiert, dürfen GitHub-User aus SETZKASTEN_ALLOWED_EMAILS als Admin reinkommen — sonst gäbe es ein Henne-Ei-Problem. Sobald der erste Admin angelegt hat, übernimmt _editors.json die Hoheit.

Setzkasten-Login (Editor:innen ohne GitHub)

Editor:innen, die keinen GitHub-Account haben, können sich per Google-Konto über Setzkasten-Login (Firebase-basiert) anmelden. Das ist eine Pro-Funktion und wird in der globalen Konfiguration aktiviert. Server-seitig läuft die Anmeldung über dasselbe _editors.json.

Lizenz-Gate

Editor-Verwaltung ist eine Pro-Funktion. Free-Lizenzen können _editors.json lesen, aber nicht ändern — das UI zeigt einen Hinweis-Banner mit „Lizenz aktivieren"- Button, der Server antwortet mit 403 + code: 'feature-locked'.

// HTTP 403 Forbidden bei Free-Tier
{
  "code": "feature-locked",
  "feature": "editors",
  "requiredTier": "pro",
  "currentTier": "free",
  "error": "Feature \"editors\" requires pro tier (current: free)."
}

Per-Website-Einschränkungen (Multi-Mode)

Im Multi-Mode hat zusätzlich jeder Eintrag in websites.json eine eigene allowedEmails-Liste. Editor:innen müssen sowohl in _editors.json als auch in der jeweiligen Website-Liste stehen. Admins passieren diese Schicht immer.