Die rollenbasierte Rechte- und Benutzerverwaltung im Vtiger CRM

Die rollenbasierte Rechte- und Benutzerverwaltung in Vtiger CRM gehört zum Pflichtteil jeder Implementation von Vtiger, sobald man mit mehr als einem Benutzer damit arbeitet. Und selbst im Falle einer Benutzung durch nur einen Nutzer ist man gut beraten, das CRM im Regelbetrieb nicht als Administrator („admin“) zu nutzen, sondern sich im Hinblick auf die Möglichkeit einer späteren Einbindung weiterer Nutzer einen separaten Benutzer anzulegen. Frank Piepiorra beschreibt die rollenbasierte Rechte- und Benutzerverwaltung in der vierten Ausgabe seines Handbuchs, indem er zunächst in die Rechteverwaltung einführt, dabei Begriffe klärt und erst dann zur Benutzerverwaltung übergeht. Seine Anleitung finde ich aber noch immer recht technisch und relativ wenig anschaulich, weshalb ich mich hier ergänzend an einer Beschreibung meiner eigenen Erfahrungen und Überlegungen zu diesem Thema versuche. Wie bereits Piepiorra schreibt, empfiehlt es sich, zunächst mit der „globalen Rechtevergabe“ zu beginnen, dann Profile und hierauf aufbauend Rollen zu definieren. Sofern die Anwendung es erfordert, lassen sich auf dieser Grundlage dann auch (Nutzer-)Gruppen definieren.

Rollen und Profile

In der Benutzerverwaltung weist man den einzelnen Benutzern Benutzungsrechte zu, indem man ihnen sogenannte Rollen zuordnet. Hierfür werden in der Benutzerverwaltung Rollen angelegt, denen man ein oder mehrere Profile zuordnet. Auch diese müssen zuvor definiert werden. In einem Profil ist ein spezifisches Bündel an Nutzungsrechten festgelegt. Konkret geht es darum, welche Bereiche des CRM genutzt werden können und welche Lese- sowie Eingabemöglichkeiten jeweils gewährt werden. Rollen stellen also eine Menge an Rechten dar, die sich aus einem oder mehreren Profilen ergeben und die der jeweilige Benutzer im System hat. Rollen erlauben in vtiger zudem die Darstellung einer Hierarchie.

Der Sinn der Definition ganz verschiedener Profile, die in einer Rolle zusammengefasst werden können, besteht darin, in Form von Profilen Tätigkeiten voneinander abzugrenzen, die man personenspezifisch – im Sinne eben der spezifischen Rolle einer Person im Unternehmen – kombinieren kann.

Ein Beispiel: Dem Mitarbeiter, der sich allein um die Kundenbetreuung kümmert, jedoch mit der Pflege der Wissensdatenbank, dem Projektmanagement oder der Verwaltung der Produkte etc. nichts zu tun hat, will man allein die Rechte zuweisen, die für die Kundenbetreuung wichtigen Bereiche wie die der Kontaktverwaltung zu benutzen. Man will ihn jedoch von der Auseinandersetzung mit anderen, eventuell noch in der Entwicklung befindlichen Bereichen entlasten. Wenn nun ein einzelner Mitarbeiter der Kundenbetreuung auch die Wissensdatenbank mitbetreuen soll, lässt sich eine weitere Rolle definieren, die neben dem Profil der Kundenbetreuung auch das Profil der Wissensdatenbankbearbeitung beinhaltet.

Profile bieten insofern dem Administrator die Möglichkeit, das System Vtiger schrittweise in das Tagesgeschäft einzuführen, indem es ihm freisteht, zunächst Rollen mit eher eng gefassten Profilen zu definieren und dann nach und nach über weitere Profile neue Bereiche des CRM in die Arbeit ausgesuchter Kollegen einfließen zu lassen. Er kann auf diese Weise seine Kollegen entlasten, da er sie dosiert mit neuen Funktionen und Aufgaben vertraut machen kann, statt sie ad hoc mit dem vollen Funktionsumfang des CRMs überfordern zu müssen.

Globale Rechtevergabe

Die „globale Rechtevergabe“ erlaubt die Festlegung, ob Benutzer Datensätze, die anderen Benutzern zugeordnet sind, lesen, erstellen/bearbeiten oder sogar löschen dürfen. Diese „globalen Rechte“ muss man für Leads, Organisationen & Personen, Dokumente, Verkaufspotentiale, Trouble Tickets und viele andere Bereiche separat festlegen.

Weil es sich bei den „globalen Rechten“ um Rechte handelt, mit anderer Leute Datensätze zu arbeiten, und die hier festgelegten Regeln für jede im System definierbare Rolle und damit für jeden Nutzer gelten, werden sie auch „öffentlich“ oder „public“ genannt. Gemeint ist die Öffentlichkeit der am System angemeldeten Benutzer, nicht aber die breite Öffentlichkeit bspw. der Internetnutzer im allgemeinen.

Wichtig ist es in einer Firma beispielsweise das Recht der anderen einzuschränken, anderer Leute Datensätze zu löschen. Das kann versehentlich oder mutwillig geschehen und für den betroffenen Nutzer einen erheblichen Schaden bedeuten. Deshalb sollte es allein beim Eigentümer eines Datensatzes liegen, ob er ihn löschen will oder nicht. Fordert ein Kollege die Löschung eines Datensatzes, kann er dies dem Eigentümer des Datensatzes sagen, statt eigenmächtig durch Löschungen Fakten zu schaffen. Ferner kann es auch sein, dass Benutzer Datensätze erstellen oder bearbeiten können sollen, die Kollegen zugeordnet sind. Beispielsweise dann, wenn Gesprächsnotizen, eine neue Telefonnummer oder dergleichen in Abwesenheit eines Kollegen hinterlegt werden soll. Dann ist es sinnvoll, global das Recht einzuräumen, Datensätze zu erstellen oder zu bearbeiten. Soll auch dies nicht sein, bleibt immer noch die Möglichkeit, das allgemeine Rechte einzuräumen, Datensätze lesen zu können. Aber auch dies kann global unterbunden werden. Infolge der Rollenhierarchie gibt es jedoch eine Einschränkung zu beachten. Die „globalen Rechte“ gelten jeweils nur auf der gleichen Hierarchieebene. Übergeordnete Hierarchieebenen haben wiederum volle Rechte. Vertriebsmitarbeiter können sich also bspw. untereinander keine Datensätze löschen, wohl aber der Vertriebsleiter Datensätze der Vertriebsmitarbeiter. Eine weitere Ausname bildet bei der „globalen Rechtevergabe“ der Kalender. Hier liegt es im Moment der Erstellung eines Termins allein beim Benutzer zu entscheiden, ob er ihn im System „öffentlich“, d.h. für andere sichtbar macht. Für den Administrator ist hier keine Möglichkeit vorgesehen, Termine grundsätzlich als öffentlich zugänglich oder bearbeitbar zu markieren.

Ergänzend zu den „globalen Rechtevergaben“ können jedoch benutzerspezifische Ausnahmen definiert werden – auch hier mit Ausnahme des Kalenders. Auf diese Weise wird es möglich, bspw. Vorgesetzten oder Gruppen zusätzlich Rechte einzuräumen oder zu nehmen. Dabei wird die Rolle oder Gruppe definiert, auf deren Datensatz zugegriffen wird und welcher Rolle oder Gruppe dabei bestimmte Rechte eingeräumt werden.

3 Kommentare

    Dave Remmel

    Vielen Dank für den Artikel. Endlich hab ich’s kapiert…

    Thomas Wohlfarth

    Das ist auf den Punkt gebracht 🙂

    eine andere Anfängerfrage, es geht dabei nur um einen Tipp, womit ich mich näher beschäftigen soll.

    Kann ich die Adressen gruppieren (also auch eine Adresse in mehreren Gruppen) und diese Gruppen dann verschiedenen Personen, mit unterschiedlichen Rollen freigeben?

    VG,
    Thomas

    Wolfgang Geitmann

    Danke – sehr hilfreich und verständlich

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

*
*