Wer darf was

Drei Rollen je Arbeitsbereich: Inhaber, Admin, Mitglied. Die Rolle hängt an der Mitgliedschaft, nicht am Konto — wer in zwei Arbeitsbereichen ist, kann in einem Inhaber und im anderen Mitglied sein.

Die tägliche Arbeit ist offen — in jedem Projekt, das du siehst

¹ So ist es voreingestellt. Inhaber und Admins ändern das unter Einstellungen → „Berechtigungen“ — siehe „Was Mitglieder mit Projekten dürfen“ unten.

Beim Stapel trennt nicht der Zugang, sondern die Menge: Inhaber und Admin dürfen 100 Zellen je Stapel, ein Mitglied 25.

Ein Projekt ist für alle sichtbar, bis der Zugriff eingeschränkt wird. Dann sehen es nur die ausgewählten Personen und Gruppen — und Inhaber und Admins, die jedes Projekt sehen. Wer ein Projekt sieht, darf darin alles, was diese Tabelle einem Mitglied erlaubt; die mit ¹ markierten Zeilen legt „Berechtigungen“ fest. Fest ausgenommen sind das Einschränken und Öffnen, das endgültige Löschen eines eingeschränkten Projekts und die Export-Vorlage des Standardprojekts. Wie das Einschränken geht, steht unter Projekte.

Was Mitglieder mit Projekten dürfen

Unter Einstellungen → „Berechtigungen“ legen Inhaber und Admins für vier Dinge fest, ob „Alle Mitglieder“ sie dürfen oder „Nur Inhaber und Admins“:

Inhaber und Admins dürfen alle vier immer. „Alle Mitglieder“ heißt bei den drei projektbezogenen Punkten: Mitglieder, die das Projekt sehen. Wer den Projektzugriff verwalten darf, fügt bei eingeschränkten Projekten, die er sieht, Personen und Gruppen hinzu und entfernt sie. Ein offenes Projekt hat keine solche Liste; ein Projekt einschränken oder für alle öffnen und Gruppen anlegen oder füllen dürfen immer nur Inhaber und Admins.

Die Einstellung gibt es in jedem Tarif. Jedes Speichern steht als „Projektrechte geändert“ im Prüfprotokoll.

Die Einstellungen sind es nicht

Lesen und Ändern fallen hier oft auseinander:

Ein Mitglied liest die Formate, die Label-Vorlagen und die Vorbelegungen, mit denen der Editor arbeitet, und die Projektfelder und die Vorlage des Arbeitsbereichs, die in den Projektangaben stehen. Es sieht nur die Verwaltungsfläche nicht.

Mitglieder verwalten

Per Einladung lassen sich nur „Mitglied“ und „Admin“ vergeben. Die Inhaber-Rolle ist über eine Einladung nicht erreichbar.

Wird ein Inhaber oder Admin zum Mitglied, sieht er danach nur noch die eingeschränkten Projekte, für die er Zugriff hat. Die Rollenänderung nennt die Projekte, die er verliert, und fragt vorher nach.

Vier Schranken, die zusätzlich gelten

1. Niemand ändert die eigene Mitgliedschaft. An der eigenen Zeile gibt es kein Menü.
2. Nur ein Inhaber darf einen Inhaber verwalten oder die Inhaber-Rolle vergeben und entziehen. Ein Admin sieht an einer Inhaber-Zeile kein Menü.
3. An einem deaktivierten Mitglied gibt es keine Rollenänderung.
4. Der Aufrufer muss selbst noch aktiv sein. Eine deaktivierte Mitgliedschaft verliert ihre Rechte sofort, auch mit gültiger Sitzung.

Abrechnung: sehen ist nicht verpflichten

Einem Admin fehlen die Kaufflächen nicht wortlos — an ihrer Stelle steht ein Satz. Ebenso beim Ausgabenlimit: Er sieht den Stand als Satz, nicht als Schalter.

Sicherheit & SSO: lesen ist nicht einrichten

Versucht ein Admin, die Verbindung zu speichern, bekommt er keinen allgemeinen Rechtefehler, sondern einen Satz, der die Rolle nennt.

Ein per Identitätsanbieter automatisch aufgenommenes Mitglied kann „Mitglied“ oder „Admin“ werden — „Inhaber“ ist als Vorgaberolle nicht wählbar.

Was ein Mitglied stattdessen sieht

Den Menüpunkt „Einstellungen“ gar nicht, und damit keine der Unterseiten. Wer die Adresse direkt aufruft, bekommt eine Seite „nicht gefunden“ — das gilt auch für den Protokoll-Export.

SSO und Abrechnung weichen davon ab: Sie zeigen dem Admin den Stand und ersetzen die Bedienelemente durch einen Satz.

Ein eingeschränktes Projekt, für das ein Mitglied keinen Zugriff hat, sieht es nirgends. Eines, das es sieht, trägt „Eingeschränkt“. Die Liste, wer sonst Zugriff darauf hat, sieht es nur, wenn es den Projektzugriff verwalten darf.

Am häufigsten trifft ein Mitglied die Rollengrenze aber gar nicht in den Einstellungen, sondern an einer Kontingentabsage beim Hochladen. Dort bekommt es keinen toten Link, sondern einen Satz, der sagt, wer handeln kann.

Einen Hinweis auf Zahlungsverzug sieht ein Mitglied nicht; den zutreffenden Satz bekommt es erst an der Absage.

Die zweite Achse: der Tarif

Rolle und Tarif sind unabhängig voneinander. Manche Inhaber-Rechte hängen zusätzlich an einer Tarifeigenschaft — „Domain eintragen“ und „SSO-Verbindung speichern“ etwa. Beide werden geprüft; die Rolle allein genügt nicht.

Ebenso beim Zugriff: Ein Projekt einschränken, Zugriff vergeben, eine Gruppe anlegen und ein Mitglied in eine Gruppe aufnehmen geht ab dem Tarif Growth. Von diesen vier darf ein Mitglied, das den Projektzugriff verwalten darf, nur eines: bei einem eingeschränkten Projekt, das es sieht, Zugriff vergeben — auch das erst ab Growth. Nach einem Wechsel in einen kleineren Tarif bleibt der Stand, wie er ist — eingeschränkte Projekte bleiben eingeschränkt. Öffnen, Zugriff entziehen, eine Gruppe umbenennen oder löschen und ein Mitglied aus einer Gruppe nehmen geht in jedem Tarif.

Die Berechtigungen hängen an keinem Tarif.