Benutzer & Rollen
Ziel: Ein neues Teammitglied einladen, ihm die richtige Rolle geben und nachvollziehen können, warum es bestimmte Datensätze sieht — und andere nicht.
Wo Sie Benutzer und Rollen verwalten
Öffnen Sie die Tenant-Administration (über das Benutzermenü erreichbar). Dort finden Sie mehrere Reiter, die für dieses Thema relevant sind:
- Benutzer — Übersicht aller Konten Ihres Systemhauses, inklusive Rollen-Zuweisung, Sperren/Reaktivieren.
- Einladungen — offene und bereits angenommene Einladungen.
- Rollen & Berechtigungen — der Rolleneditor.
Neuen Mitarbeitenden einladen
Codemeta OS legt Konten ausschließlich per Einladung an — es gibt keine Möglichkeit, direkt ein Passwort für eine andere Person zu vergeben. Das ist bewusst so: Die eingeladene Person setzt ihr eigenes Passwort bzw. ihren eigenen Passkey selbst, Sie als Admin bekommen es nie zu Gesicht.
So geht’s:
- Auf dem Reiter „Benutzer“ oder „Einladungen“ den Button „Benutzer einladen“ anklicken.
- Im Dialog „Benutzer einladen“ ausfüllen:
| Feld | Bedeutung |
|---|---|
| E-Mail-Adresse | Pflichtfeld — an diese Adresse geht der Einladungslink. |
| Rolle | Welche interne Rolle die Person bei Annahme der Einladung erhält (z. B. Technik, Vertrieb, Administrator). |
| Persönliche Nachricht (optional) | Wird in der Einladungs-E-Mail mit angezeigt. |
- Mit „Einladung senden“ abschicken.

Das Lizenz-Paket der Person weisen Sie nicht im Einladungs-Dialog zu, sondern nachträglich in der Spalte „Lizenz-Paket“ der Benutzer-Übersicht.
Je nach E-Mail-Zustellung sehen Sie danach eine von drei Rückmeldungen: eine erfolgreiche Zustellung, eine erfolgreiche Zustellung über die Absenderadresse noreply@codemeta.de, oder den Hinweis, dass die E-Mail nicht versendet werden konnte und Sie den Einladungslink manuell teilen müssen.
Benutzer sperren statt löschen
Konten werden nicht gelöscht, sondern gesperrt — der Zugriff wird entzogen, die Historie (wer hat wann was gemacht) bleibt erhalten. Über die Aktion „Sperren“ an einem Benutzer öffnet sich der Dialog „Benutzer sperren?“: Die Person kann sich danach nicht mehr anmelden, alle aktiven Sitzungen werden sofort beendet. Optional können Sie einen Grund hinterlegen. Über „Reaktivieren” heben Sie die Sperre wieder auf.
Zwei Schutzmechanismen verhindern, dass sich ein Systemhaus versehentlich aussperrt:
- Der letzte aktive Administrator kann nicht gesperrt oder entfernt werden.
- Der/die Eigentümer:in kann nicht gesperrt werden — dafür muss die Eigentümer-Rolle zuerst auf ein anderes Konto übertragen werden.
Rollen zuweisen
In der Benutzer-Übersicht hat jede Person eine Rollen-Zuweisung, die auch mehrere Rollen gleichzeitig umfassen kann. Ein Klick auf die Rollen-Zelle öffnet die Mehrfachauswahl. Welche Rollen zur Auswahl stehen, legen Sie im Reiter „Rollen & Berechtigungen“ fest.

Systemrollen vs. eigene Rollen
Codemeta OS unterscheidet zwei Arten von Rollen:
- Systemrollen — vordefiniert (z. B. Eigentümer, Admin), im Editor als „Systemrolle (schreibgeschützt)“ markiert. Name, Beschreibung und Berechtigungen lassen sich nicht direkt bearbeiten. Sie können eine Systemrolle aber über „Duplizieren” als Ausgangspunkt für eine eigene Rolle verwenden, und Sie können sie über „Deaktivieren“ aus der künftigen Zuweisung nehmen (bestehende Zuweisungen bleiben bestehen). Rollen mit besonders weitreichenden Rechten lassen sich aus Sicherheitsgründen weder deaktivieren noch löschen.
- Eigene Rollen — von Ihnen über „Neue Rolle“ angelegt, frei benennbar und vollständig editierbar, inklusive Löschen.
Wie Zugriff wirklich funktioniert: zwei getrennte Ebenen
Das ist der Teil, den die meisten Admin-Fehlkonfigurationen betrifft — deshalb ausführlich: Ob eine Person etwas sehen oder bearbeiten kann, entscheidet sich in zwei unabhängigen Schritten, nicht in einem.
Schritt 1 — Berechtigung: darf die Rolle das grundsätzlich?
Im Rolleneditor legen Sie pro Bereich (Tickets, Verträge, Assets, …) fest, ob eine Rolle dort grundsätzlich erstellen, lesen, bearbeiten oder löschen darf — das sind die Häkchen auf dem Reiter „Schema-Rechte“. Zusätzlich gibt es auf „Spezialrechte“ ein paar Berechtigungen, die keine Datensatz-Aktion sind, sondern eine Fähigkeit freischalten (z. B. Rollen selbst verwalten).
Diese Ebene beantwortet nur die Frage: Darf diese Rolle Tickets grundsätzlich lesen? — nicht, welche Tickets.

Schritt 2 — Sichtbarkeit: welche Datensätze genau?
Genau dafür gibt es den Reiter „Sichtbarkeit“. Er entscheidet, welcher Ausschnitt der erlaubten Datensätze tatsächlich sichtbar bzw. bearbeitbar ist. Zur Auswahl stehen unter anderem:
| Option | Bedeutung |
|---|---|
| Alle Einträge | Uneingeschränkter Zugriff auf alle Datensätze dieses Bereichs. |
| Mir zugewiesen | Nur Datensätze, die der eigenen Person zugewiesen sind. |
| Mein Team (alles mit Team-Zuordnung) | Alles, was dem eigenen Team zugeordnet ist — auch wenn es zusätzlich einer bestimmten Person zugewiesen ist. |
| Meinem Team zugewiesen (offener Pool) | Nur die Datensätze im offenen Team-Pool, die noch keiner Person zugewiesen sind. |
| Jemandem aus meinem Team zugewiesen | Datensätze, die einer Person aus dem eigenen Team zugewiesen sind — auch ohne eigene Team-Zuordnung des Datensatzes. |
| Meine Kunden | Datensätze, die zu Kunden gehören, mit denen die eigene Person verknüpft ist. |
| Von mir erstellt | Nur selbst angelegte Datensätze. |
Beide Schritte zusammen ergeben die tatsächliche Berechtigung. Eine Rolle, die auf „Schema-Rechte“ Lese-Zugriff auf Tickets hat, aber auf „Sichtbarkeit“ nur „Mir zugewiesen“ gesetzt bekommt, sieht ausschließlich die eigenen Tickets — obwohl die Berechtigung formal „Tickets lesen“ heißt und nicht einschränkt scheint. Umgekehrt bringt die großzügigste Sichtbarkeit nichts, wenn die Grund-Berechtigung fehlt: Ohne „Tickets lesen“ auf Schema-Rechte sieht die Rolle gar keine Tickets, egal was auf „Sichtbarkeit“ steht.
Für einzelne Bereiche mit komplexeren Anforderungen — zum Beispiel „alle Rechnungen sehen, aber bei Anhängen nur die eigenen Kunden“ — lässt sich die Sichtbarkeit statt im einfachen Modus auch im Modus „Bedingt“ konfigurieren: WENN-DANN-Regeln mit UND-Bedingungen, plus einer SONST-Regel als Auffangfall. Für die meisten Rollen reicht der einfache Modus „Einfach“ völlig aus.