Skip to main content

Berechtigungen für Stammdatentabellen

Stammdatentabellen können in Squeeze mit einem feingranularen, rollenbasierten Berechtigungssystem geschützt werden. Damit lässt sich pro Tabelle und pro Rolle festlegen, wer die Daten einer Tabelle bearbeiten und wer die Tabelle selbst verwalten darf.

Dieses feingranulare System ist nur aktiv, wenn das Feature-Flag masterDataTablePermissions für den Mandanten aktiviert ist (siehe Features verwalten). Ist das Flag deaktiviert (Standard), gelten ausschließlich die globalen Berechtigungen (siehe unten).

Zwei Berechtigungsstufen

Das System unterscheidet zwei Aktionen auf einer Stammdatentabelle. Jede ist an eine globale Berechtigung (einen Scope, den eine Rolle erhalten kann) gekoppelt:

StufeGlobale Berechtigung (Scope)Erlaubt
Verwalten (manage)sqz_masterdata_manageTabellen anlegen, ändern und löschen; Spalten und Schema pflegen; die Berechtigungen der Tabelle pflegen
Bearbeiten (edit)sqz_masterdata_editDatenzeilen einer Tabelle anlegen, ändern und löschen (inkl. CSV- und Batch-Upload)

LesendeDie meisten lesenden Zugriffe (Tabellen auflisten, Spalten anzeigen, Zeilen suchen, CSV-Export)suchen) sind nicht durch diese Berechtigungen geschützt und stehen jedem authentifizierten Benutzer offen. Ausnahme: der CSV-Export – dieser wird gesondert geprüft (siehe Abschnitt „Sonderfall: CSV-Export").

Verhalten bei deaktiviertem Feature-Flag (Standard)

Ohne aktiviertes Flag entscheidet ausschließlich die globale Berechtigung:

  • Verwalten-Endpunkte erfordern den Scope sqz_masterdata_manage.
  • Bearbeiten-Endpunkte erfordern den Scope sqz_masterdata_edit.

Eine tabellen- oder rollenspezifische Feinsteuerung findet nicht statt. Bereits hinterlegte Tabellen-Berechtigungen bleiben ohne Wirkung, bis das Flag aktiviert wird.

Verhalten bei aktiviertem Feature-Flag

Ist das Flag aktiv, wird der Zugriff auf einedie schreibenden Endpunkte (Tabelle verwalten bzw. Daten bearbeiten) in dieser Reihenfolge entschieden:

  1. Globale Berechtigung zuerst: Besitzt eine Rolle des Benutzers den globalen Scope (sqz_masterdata_manage bzw. sqz_masterdata_edit), ist der Zugriff auf alle Tabellen erlaubt. Die globale Berechtigung wirkt damit wie eine „Wildcard".
  2. Sonst tabellenspezifisch: Andernfalls werden die für die betroffene Tabelle hinterlegten Berechtigungen geprüft. Hat der Benutzer eine Rolle, für die in dieser Tabelle das passende Recht (canEdit bzw. canManage) gesetzt ist, wird der Zugriff gewährt.
  3. Andernfalls verweigert: Trifft nichts davon zu, wird der Zugriff mit „nicht autorisiert" (HTTP 403) abgelehnt.

Die tabellenspezifischen Berechtigungen sind also additiv zur globalen Berechtigung: Der globale Scope gibt Vollzugriff auf alle Tabellen, während tabellenspezifische Einträge einzelnen Rollen gezielt Rechte für einzelne Tabellen einräumen.

Der CSV-Export folgt dieser Reihenfolge nicht – siehe den nächsten Abschnitt.

Das Tabellen-Berechtigungsobjekt

Eine tabellenspezifische Berechtigung gilt jeweils für die Kombination aus einer Tabelle und einer Rolle:

FeldTypBedeutung
tableIdintegerID der Stammdatentabelle
roleIdintegerID der Rolle, für die die Berechtigung gilt
canEditbooleanDie Rolle darf die Datenzeilen der Tabelle bearbeiten
canManagebooleanDie Rolle darf die Tabelle verwalten (Struktur, Spalten, Schema und Berechtigungen)

Das Pflegen der Berechtigungen einer Tabelle zählt selbst zu „Verwalten". Nur wer canManage für die Tabelle (bzw. den globalen Scope sqz_masterdata_manage) besitzt, kann deren Berechtigungen ändern.

Sonderfall: CSV-Export

Der CSV-Export einer Tabelle (GET /masterData/tables/{tableId}/csv) wird bei aktiviertem Feature-Flag gesondert und abweichend von der übrigen Zugriffslogik geprüft:

  • Der Export ist nur erlaubt, wenn der Benutzer eine Rolle besitzt, für die in dieser Tabelle eine tabellenspezifische Berechtigung mit canEdit = true hinterlegt ist. Andernfalls antwortet die API mit HTTP 403.
  • Abweichend von den schreibenden Endpunkten wird hierbei der globale Scope sqz_masterdata_edit nicht berücksichtigt – ein rein global vergebenes Bearbeiten-Recht genügt für den CSV-Export also nicht.
  • Ebenso genügt canManage allein nicht; geprüft wird ausschließlich canEdit.

Erhält ein Benutzer bei aktiviertem Feature-Flag ein HTTP 403 beim CSV-Export, obwohl er die Tabelle verwalten oder anderweitig darauf zugreifen kann, fehlt ihm mit hoher Wahrscheinlichkeit ein canEdit-Eintrag für genau diese Tabelle. Weisen Sie einer seiner Rollen eine Tabellen-Berechtigung mit canEdit = true zu.

Konfiguration über die API

Die tabellenspezifischen Berechtigungen werden über die REST-API gepflegt. Der Request-Body entspricht dem oben beschriebenen Objekt (roleId, canEdit, canManage).

Lesen:

  • GET /masterData/tables/{tableId}/permissions – alle Berechtigungen einer Tabelle
  • GET /masterData/tables/{tableId}/permissions/role/{roleId} – Berechtigung einer bestimmten Rolle
  • GET /masterData/tables/{tableId}/permissions/user/{userId} – effektive Rechte eines Benutzers

Schreiben (erfordert Verwalten-Recht):

  • POST /masterData/tables/{tableId}/permissions – Berechtigung anlegen
  • PUT /masterData/tables/{tableId}/permissions – Berechtigung aktualisieren
  • DELETE /masterData/tables/{tableId}/permissions – Berechtigung löschen
  • POST / PUT / DELETE /masterData/tables/{tableId}/permissions/role/{roleId} – rollenspezifische Pflege

Verwandte Themen

Back to top