Benutzergruppen regeln, was jemand grundsätzlich darf. Daneben gibt es feiner einstellbare Elementberechtigungen, die nicht in jeder Gruppe liegen, sondern an einzelnen Objekten hängen: Projektrollen am Projekt, Schutzklassen am sensiblen Element. Und es gibt Sachbearbeiterrechte als bewusst eingebautes Schlupfloch, um Restriktionen gezielt zu umgehen.
Projektrollen – wer in welchem Projekt was darf
Während die grundsätzliche Berechtigung sagt „darf jemand überhaupt Projekte sehen”, regeln Projektrollen das projektbezogene Recht: Wer darf in diesem konkreten Projekt was machen oder sehen? Du bist ja nicht in jedem Projekt verantwortlich, sondern nur in einigen.
- Die gängigsten Rollen sind Bearbeiter und Verantwortlicher.
- Projektrollen lassen sich selbst definieren und sind sehr mächtig – ähnlich wie Benutzergruppen. Darüber steuerst du z. B., wer auf welche Projekte Zeiten buchen darf, wer den Plan ändern darf oder wer ein Projekt überhaupt sieht und Verantwortliche einteilen darf.
- Definiert werden die Rollen im Tab Projektrollen der Kategorie
Benutzer & Rechte; zugewiesen werden sie dann projektspezifisch – in dem einen Projekt bist du verantwortlich, im anderen nur Bearbeiter.
Über das Stammdaten-Feld Standard-Projektrolle für neue Projekte an einer Benutzergruppe bekommen deren Mitglieder bei jedem neuen Projekt automatisch die hinterlegte Rolle.
Schutzklassen – Schutz direkt am Element
Eine Schutzklasse hängst du an einzelne Dinge – z. B. an Gehaltsdaten, Arbeitsverträge oder sensible Dateien. Bekommst du über deine Benutzergruppe die passende Schutzklasse zugewiesen, darfst du alles sehen, was mit dieser Klasse geschützt ist – sonst nicht.
So funktioniert es:
- Du definierst eine Schutzklasse frei (z. B.
Gehalt). - Du gibst diese Schutzklasse einer Benutzergruppe (im Reiter Berechtigungen).
- Du schützt einzelne Elemente mit dieser Klasse.
Genutzt wird das meist im HR-Bereich: Gehaltsdaten bekommen z. B. eine andere Schutzklasse als die Wochenarbeitszeiten – so sehen verschiedene Rollen unterschiedlich viel.
Auch über Dateiklassen. Du kannst eine Dateiklasse (z. B.
Arbeitsverträge) definieren und ihr eine Schutzklasse zuordnen. Alle Dateien dieser Klasse sind dann automatisch geschützt – und gleichzeitig als „Arbeitsvertrag” gekennzeichnet. Über einzelne Elemente hinaus tragen auch eine Datei im Verzeichnis, eine Wiki-Seite und viele andere Elemente eigene Berechtigungen, mit denen du festlegst, wer genau sie sehen oder ändern darf.
Sachbearbeiterrechte – das bewusste Schlupfloch
In teamspace müssen alle für eine Aktion nötigen Rechte erfüllt sein. Ist ein Element besonders geschützt und dir fehlt das eine Recht – dann geht es nicht. Genau dafür gibt es einen geplanten Ausweg: optionale Sachbearbeiterrechte, die andere Restriktionen gezielt übergehen.
Typisches Beispiel: ein Sachbearbeiter Finanzen, der alle Rechnungen sehen soll – auch wenn die Rechnung in einem Projekt hängt, auf das er gar keinen Zugriff hat, und ohne dass du ihn in jedes Projekt einträgst. Der Schalter sitzt in den Berechtigungen der Gruppe, z. B. als Sachbearbeiter Finanzen (Zugriff auf alle Belege, unabhängig von den Projektrechten).
⚠ Schlupflöcher sparsam einsetzen. Ein Sachbearbeiterrecht hebelt absichtlich die normale UND-Logik aus. Vergib es nur dort, wo eine Funktionsrolle wirklich modulweiten Zugriff braucht – nicht als bequeme Abkürzung um ein sauberes Gruppenmodell herum.
Wo Elementberechtigungen ins Gesamtbild passen
Elementberechtigungen sind die vierte Säule neben den Gruppen-Ebenen:
- Benutzergruppen → grundsätzliche Rechte (sehen, anlegen, …)
- Gruppenspezifische Berechtigungen → personenbezogene Rechte
- Projektrollen → was du in diesem Projekt darfst
- Schutzklassen / Element-Rechte → Schutz am einzelnen Objekt
Wie die Ebenen zusammenwirken, steht in Wie Berechtigungen zusammenwirken.
Verwandte Themen
- Wie Berechtigungen zusammenwirken – die sechs Ebenen Berechtigungen Konzept
- Gruppenspezifische Berechtigungen einrichten (mit Video) Berechtigungen Konfiguration
- Thema: Projektmanagement Projektmanagement