Rollen und Gruppen

Wer die Documents Partner API nutzen darf, entscheidet sich an einer Rolle. Eine Rolle erreicht einen Benutzer aber ausschließlich über eine Gruppe – einen anderen Weg gibt es in der STP Cloud nicht.

Dieser Artikel erklärt beides – und warum das für Sie vor allem eine Erleichterung ist.

Die drei Rollen

In der Benutzerverwaltung sehen Sie den Anzeigenamen; der technische Name daneben taucht in Konfigurationen und in Rückfragen beim Support auf.

Für die Documents Partner API gibt es keine weiteren Rollen, insbesondere keine partnerspezifischen: Dieselben drei gelten, gleich mit welchem Partnerprodukt Sie arbeiten.

Das Partnerprodukt selbst kann eigene Rollen mitbringen. Was eine Anwendung wie BEAMON AI in sich an Rechten unterscheidet, ist Sache dieses Produkts und hat mit den Rollen hier nichts zu tun. Diese drei entscheiden ausschließlich, was über die Documents Partner API am Dokumentenmanagement möglich ist.

Die Rolle ist nur die eine Hälfte. Sie öffnet die Schnittstelle. Welche Akten und Dokumente ein Benutzer tatsächlich sehen und ändern darf, entscheidet weiterhin die Berechtigungsverwaltung Ihres lokalen Dokumentenmanagements für genau diesen Benutzer – siehe Lizenzen und Berechtigungen.

Der Weg zur Rolle führt über eine Gruppe

Eine Rolle wird einer Gruppe zugeordnet, und Benutzer werden Mitglied dieser Gruppe. Wer in keiner Gruppe ist, die eine Rolle trägt, hat die Rolle nicht.

Benutzer  →  Gruppe  →  Rolle  →  Berechtigungen

Es gibt keinen Weg an der Gruppe vorbei. Die STP Cloud kennt keine Rollenzuweisung direkt an einem Benutzer – die Benutzerverwaltung bietet das gar nicht erst an. Wer einem Konto eine Berechtigung geben will, fügt es einer Gruppe hinzu, die die passende Rolle trägt. Etwas anderes gibt es nicht.

Die Standardgruppen

Damit Sie nichts einrichten müssen, liefern wir für jede Rolle eine fertige Gruppe mit. Sie ist in jedem Mandanten bereits vorhanden:

So sehen sie in der Benutzerverwaltung unter Gruppen aus – die Spalte Rollen zeigt, welche Rolle jede Gruppe trägt:

Im Regelfall genügt es also, das betreffende Benutzerkonto der passenden Gruppe hinzuzufügen. Anlegen müssen Sie nichts.

Das ist der empfohlene Weg – er ist der kürzeste, und er bleibt richtig, wenn wir künftig Rollen ergänzen.

Wenn eine Standardgruppe fehlt

Findet die Suche eine der drei Gruppen nicht, wurde sie entweder umbenannt, gelöscht – oder der Mandant wurde eingerichtet, bevor es sie gab. Nachlegen lässt sie sich mit einem Klick:

Über der Gruppenliste liegt die Schaltfläche „Fehlende Standardgruppen wiederherstellen“. Sie zeigt zunächst, was angelegt würde:

Die Liste umfasst alle fehlenden Standardgruppen des Mandanten, nicht nur die der Documents Partner API. Im Bild sind die Einträge anderer STP-Anwendungen geschwärzt; bei Ihnen stehen dort die Gruppen der Anwendungen, die Ihre Kanzlei einsetzt. Mit Speichern werden sie angelegt.

Zwei Punkte dazu:

• Der Vorgang legt nur an, er ändert nichts. Bereits vorhandene Gruppen bleiben unangetastet, samt ihrer Mitglieder.
• Mitglieder kommen nicht mit. Eine wiederhergestellte Gruppe ist leer; die Konten müssen ihr anschließend hinzugefügt werden.

Eigene Gruppen zuschneiden

Die Standardgruppen sind ein Angebot, keine Vorschrift. Als Administrator Ihres Mandanten können Sie eigene Gruppen bilden und ihnen die Rollen der Documents Partner API zuweisen – allein oder zusammen mit Rollen anderer STP-Anwendungen.

Sinnvoll ist das vor allem in zwei Fällen:

Dabei gilt:

• Eine Gruppe kann mehrere Rollen tragen, und eine Rolle kann in mehreren Gruppen vorkommen.
• Ein Benutzer kann in mehreren Gruppen sein. Seine Berechtigungen sind die Summe der Rollen aus allen Gruppen.
• Die Standardgruppen bleiben bestehen, auch wenn Sie eigene anlegen. Sie können sie parallel verwenden oder unbenutzt lassen.

DmsCloudApi.User und DmsCloudApi.User.Reader gemeinsam ergeben keinen Sinn. DmsCloudApi.User enthält das Lesen bereits. Wer über zwei Gruppen beide Rollen erhält, darf schreiben – die Leserolle ändert daran nichts. Wenn ein Konto ausdrücklich nicht schreiben können soll, darf es in keiner Gruppe sein, die DmsCloudApi.User trägt.

Welche Rolle für wen

Warum das Connector-Anmeldekonto mit einer Rolle auskommt. DmsCloudApi.Connector berechtigt zu genau einer Sache: den Connector an den Nachrichtenvermittler anzumelden. Auf die Schnittstelle selbst greift der Connector nie zu, also kann diese Rolle auch keine Dokumente lesen oder schreiben.

Die eigentliche Arbeit im Dokumentenmanagement geschieht ohnehin nicht unter diesem Konto, sondern unter dem des Benutzers, dessen Anfrage gerade bearbeitet wird. Die beiden anderen Rollen zusätzlich zu vergeben, würde dem Connector daher nichts nützen – es würde nur die Rechte dieses einen Kontos an anderer Stelle erweitern.

Ist dieselbe Person auch Anwenderin einer Partneranwendung, gehört sie natürlich zusätzlich in die passende Anwendergruppe. Das ist dann aber ihre Rolle als Anwenderin, nicht die des Connectors.

Wenn eine Berechtigung nicht greift

Die Prüfreihenfolge, die die meisten Fälle löst:

1. Ist das Konto Mitglied einer Gruppe, die die Rolle trägt? Die Mitgliedschaft ist der einzige Weg – ohne sie hat das Konto die Rolle nicht.
2. Trägt die Gruppe wirklich die passende Rolle? Bei eigenen Gruppen lohnt der Blick in die Spalte Rollen.
3. Gibt es die Gruppe überhaupt? Fehlt eine Standardgruppe, lässt sie sich wiederherstellen – siehe oben.
4. Ist ein neues Token geholt worden? Rollenänderungen wirken erst im nächsten Token – ein bestehendes bleibt bis zum Ablauf unverändert, üblicherweise eine Stunde.
5. Besitzt der Mandant die passende Lizenz? Ohne sie greift keine Rolle – siehe Lizenzen und Berechtigungen.

Weiterführend

• Lizenzen und Berechtigungen
• Erste Schritte