Basisberechtigungen
Basisberechtigungen werden an "umgebenden" Objekten für Businessobjekte hinterlegt.
Businessobjekte sind Tickets, Assets, FAQ-Artikel, Kontakte und Organisationen. Damit ergeben sich folgende "Paarungen":
Tickets und Teams/Queues
Assets und Assetklassen
FAQ-Artikel und FAQ-Kategorien
Kontakte und Organisationen
Tickets und Organisationen
Hinweis
Aktuell sind Basisberechtigungen nur für Tickets in Teams/Queues möglich. Mittelfristig wird dieser Ansatz auf weitere Paarungen ausgeweitet.
Basisberechtigungen können nur an Team-Einstellungen gesetzt werden. Sie unterstützen kein DENY, sondern basieren ausschließlich auf Basepermission-Read, Basepermission-Write und Basepermission-Read&Write.
Die Basisberechtigungen für Tickets in Teams (Queues) werden direkt beim Anlegen/Bearbeiten eines Teams erteilt. Dabei werden Rollen ausgewählt und deren jeweiligen Berechtigungen in Bezug auf das Team hinterlegt.
Read: erlaubt das Lesen von Tickets in diesem Team.
Es ist keine Veränderung oder Bearbeitung an dem Ticket möglich.
Write: erlaubt das Erstellen und Verschieben von Tickets in diesem Team.
Das Ticket kann ohne Read im weiteren jedoch nicht eingesehen werden.
Read & Write: entspricht einem Vollzugriff.
Diese Berechtigung wird benötigt um ein Ticket in irgendeiner Weise zu bearbeiten.
Anmerkung
Für die häufigsten Anwendungsfälle wie die Beschränkung des Zugriffs auf Tickets basierend auf der Teamzuordnung des Tickets werden nur die Basisberechtigungen benötigt.
Weiterhin sind die Basisberechtigungen Grundlage für die Ermittlung der an zu erstellenden oder zu bearbeitenden Tickets auswählbaren Teams/Queues und auf diesen basierend auch der Bearbeiter/Verantwortlichen.
Weiterführende Informationen finden Sie unter: Basisberechtigungen
Abb.: Pflege der Basisberechtigungen im Team Service Desk
Basisberechtigungen wirken grundsätzlich wie Objektberechtigungen: Sie steuern, ob der Zugriff auf ein Businessobjekt erlaubt wird. Sie wirken direkt nach Ressourcenberechtigungen.
Das heißt, zunächst muss eine Berechtigung bestehen, überhaupt auf eine Ressource (bspw. /tickets ) zugreifen zu dürfen. Danach werden die Basisberechtigungen geprüft. Wenn dieser Zugriff zulässig ist, werden weitere Objektberechtigungen geprüft und schließlich Eigenschaftsberechtigungen angewandt.
Abb.: Ablauf Berechtigungsprüfung mit Basisberechtigungen (Einordnung in Berechtigungskonzept)
Um in einem Team X ein Ticket zu erstellen, benötigt der ausführende Nutzer mindestens Write-Berechtigungen auf das gewählte Team. Umgekehrt bedeutet dies, dass der Nutzer nur die Teams auswählen kann, in denen er die erforderliche Berechtigung hat. Die Auswahl der Teams in Ticketerstellung und -bearbeitung wird eingeschränkt.
Um in einem Team X ein Ticket zu bearbeiten, benötigt ein Nutzer Read & Write-Berechtigung auf das Team, in dem sich das Ticket befindet. Umgekehrt bedeutet dies, dass der Nutzer nur solche Agenten als Bearbeiter oder Verantwortlicher setzen kann, die im Team diese Berechtigung inne haben. Die Auswahl der Bearbeiter und Verantwortlichen in Ticketerstellung und -bearbeitung wird eingeschränkt. Das betrifft auch die Sammelaktion auf Tickets.
Bei der Suche nach Tickets und in der Teamansicht stehen nur die Teams zur Verfügung, auf welche der Nutzer (mindestens) Read-Berechtigung hat. Auch können nur die Tickets eingesehen werden, auf deren Teams (mindestens) Read-Berechtigung besteht.
Die Basisberechtigungen wirken für jeden Nutzer - unabhängig vom Kontext. Das heißt, sie wirken auch im Self Service Portal.
Im Adminbereich und bei der Konfiguration von Jobs, Macro Actions, Benachrichtigungsregeln o. a. Automatismen gelten diese Einschränkungen für Auswahlen von Teams nicht.
Bevor Objektberechtigungen vergeben werden, müssen die Möglichkeiten der Basisberechtigungen ausgeschöpft werden. Der bisherige Ansatz für Berechtigungen tritt für Sonderfälle zurück, welche auf anderen Kriterien als auf Team-Berechtigungen basieren.
Damit bestehende Installationen einen Performanz-Gewinn verzeichnen können, ist ein Wechsel von Objektberechtigungen auf Basisberechtigungen erforderlich. Die bisherigen Berechtigungen ermöglichten keine korrekte Auswahl von Bearbeiter, Verantwortlicher oder Team. Berechtigungsszenarien, welche auf Teams/Queues basieren, sollten daher überarbeitet werden. Zwingend erforderlich ist dies jedoch nicht. Die bisherigen Berechtigungen gelten weiterhin, stellen aber eine weitere Belastung der Performance dar.
Die initial mit KIX initial ausgelieferten Berechtigungsrollen werden auch weiterhin wie beschrieben wirken:
Rolle "Customer": erlaubt weiterhin den vollen Zugriff eines SSP-Nutzers entsprechend den Möglichkeiten und Berechtigungen im Self Service Portal.
Rolle "Ticket Reader": erlaubt weiterhin den lesenden Zugriff auf alle Tickets, unabhängig davon, in welchem Team/Queue diese liegen.
Rolle "Ticket Agent": erlaubt weiterhin den vollen Zugriff auf alle Tickets, unabhängig davon, in welchem Team/Queue diese liegen.
Rolle "Ticket Agent Base Permission" beinhaltet die grundlegenden Berechtigungen zum Bearbeiten von Tickets ohne konkrete Queuezuordnungen.
In Verbindung mit Team-/Queue-spezifischen Rollen wird sie verwendet, um Mitarbeit/-lesen in spezifischen Queues zu erlauben. Diese Rolle ist die Grundlage für team-spezifische Mitarbeit.
Rolle "Ticket Agent (w/o teams)" beinhaltet zwar weiterhin die grundlegenden Berechtigungen zum Bearbeiten von Tickets ohne konkrete Queuezuordnungen, kann aber in Zusammenhang mit Basisberechtigungen nicht verwendet werden. Sie wird daher zukünftig entfallen.
Zum Vergeben teamspezifischer Berechtigungen, empfehlen wir folgendes Vorgehen:
Legen Sie die spezifischen Rollen für die Basisberechtigungen an.
Diesen Rollen müssen manuell keine Berechtigungen zugestanden werden. Das reine Erstellen reicht aus.
Teams (Queues) anlegen oder bearbeiten.
Hinterlegen Sie am Team, welche Rolle welche Berechtigung innerhalb dieses Teams hat.
Sie können die im 1. Schritt angelegten Rollen sowie alle anderen im System vorhandenen Rollen angeben.
Die gewählten Rollen erhalten damit automatisch die gesetzten Basisberechtigungen.
Ordnen Sie den betreffenden Nutzern mindestens die Rollen "Agent User", "Ticket Agent Base Permissions" sowie die spezifischen Rollen aus Schritt 1 zu.
Die in den Teams/Queues erteilten Basisberechtigungen für Tickets werden automatisch in den entsprechenden Rollendefinitionen hinterlegt. Dazu gibt es neben "Resource", "Object" und "Property" auch "Base::Ticket" als Berechtigungs-Layer. Das Ziel ist dabei eine einzelne Queue-ID.
Sollen Basisberechtigungen für alle Teams (Queues) gesetzt werden, kann anstatt aller Queue-IDs ein Sternchen ( * ) als Wildcard eingetragen werden.
Abb.: Berechtigungs-Layer und Berechtigungen
Die Basisberechtigungen werden wie folgt abgebildet:
Basisberechtigung | Abbildung |
|---|---|
Read | -R--- (Read) |
Write | C-U-- (Create, Update) |
Read & Write | CRUD- (Create, Read, Update, Delete) |
Basisberechtigungen auf Tickets erweitern
Sie können die Basisberechtigungen der Agenten erweitern, sodass diese auf Tickets zugreifen können, auch ohne die entsprechenden Basisberechtigungen zu besitzen. Geregelt wird dies über folgende Konfigurationsschlüssel (Menü ).
Beachten Sie dabei jedoch die Abhängigkeit zur automatischen Prüfung der Basisberechtigungen.
Dieser Konfigurationsschlüssel erweitert die Basisberechtigungen der Agenten auf ehemalige Tickets.
Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).
Wenn aktiviert (gültig): Agenten können auf ein Ticket zugreifen, welches zu irgendeinem Zeitpunkt in einem der unter Meine Teams (Persönliche Einstellungen des Agenten) gesetzten Teams war, auch wenn sich dieses Ticket jetzt in einem Team befindet, auf welches sie sonst keinen direkten Zugriff haben.
Wichtig
Der Agent benötigt auf das betreffende Team zum aktuellen Zeitpunkt zwingend Lese- und Schreibrechte.
Der Konfigurationsschlüssel ist initial inaktiv (ungültig). Sie können ihn bei Bedarf aktivieren. Suchen und öffnen Sie dazu den Konfigurationsschlüssel im Menü und setzen Sie die Gültigkeit auf gültig.
Der Parameter Permission definiert, welche Rechte die Agenten auf die betreffenden Tickets haben. Mögliche Werte sind:
READ: nur LeseberechtigungRW: Lese- und Schreibrechte
Hinweis
Diese Konfiguration wirkt sich lediglich auf die Basisberechtigungen aus. Sie hat keinen Einfluss auf andere Berechtigungsstufen.
Warnung
Für die Berechtigungsprüfung muss die Tickethistorie geprüft werden, was zur Verschlechterung der Systemperformanz führen kann.
Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).
Wenn aktiviert (gültig): Agenten, welche als Bearbeiter am Ticket gesetzt sind, können auf das Ticket zugreifen, auch wenn sie nicht die entsprechenden Basis-Berechtigungen (z. B. auf das Team) haben.
Wichtig
Deaktivieren Sie zuvor den SysConfig-Schlüssel , da die Konfigurationsschlüssel sonst miteinander konkurrieren würden.
Hinweis
Eine Anzeige von solch indirekt sichtbaren/bearbeitbaren Tickets in Ticketlisten oder Suche erfolgt nicht. Der Zugriff auf das Objekt ist nur per URL-Direktaufruf oder vom Eltern-Ticket ausgehend möglich.
Anmerkung
Diese Konfiguration wirkt sich nur auf Basis-Berechtigungen aus.
Vererbt die Berechtigungen des Eltern-Tickets auf die Kind-Tickets.
Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).
Wenn aktiviert (gültig): Agenten mit Berechtigung auf ein Eltern-Ticket können auch auf dessen Kind-Tickets zugreifen, ohne dass sie über Basis-Berechtigungen auf Kind-Tickets verfügen. Es werden die Basis-Berechtigungen des Eltern-Tickets vererbt.
Das heißt:
Besteht auf ein Ticket "A" READ-Zugriff als Basis-Berechtigung, so kann jedes Kind-Ticket von "A" ebenfalls gelesen werden.
Besteht auf ein Ticket "B" READ+WRITE-Zugriff als Basis-Berechtigung, so kann jedes Kind-Tticket von "B" ebenfalls gelesen und aktualisiert werden.
Somit kann bspw. der Agent auch ohne grundsätzliche Berechtigungen auf Teams Unteraufträge nachverfolgen und ergänzen. Der Zugriff auf die Kind-Tickets erfolgt dabei nur auf direkte Links. Diese Tickets tauchen nicht in Ticketlisten auf.
Voraussetzung für den Zugriff auf ein Kind-Ticket ist eine bestehende Verknüpfung zwischen Eltern- und Kind-Ticket vom Typ "ParentChild". Die Verknüpfung muss zwingend über das Dynamische Feld ParentTickets erfolgen. Eine Verknüpfung mit dem Dynamischen Feld ChildTickets funktioniert nicht. Gegebenenfalls müssen Sie das Dynamische Feld ParentTickets in eine Aktion (z. B. Ticket Edit) bzw. in eine Vorlage (z. B. Default - New Ticket Template) integrieren.
Hinweis
Eine Anzeige von solch indirekt sichtbaren/bearbeitbaren Tickets in Ticketlisten oder Suche erfolgt nicht. Der Zugriff auf das Objekt ist nur per URL-Direktaufruf oder vom Eltern-Ticket ausgehend möglich.
Anmerkung
Diese Konfiguration wirkt sich nur auf Basis-Berechtigungen aus.
Der Parameter MaxGenerations definiert, auf wie viele Ebenen sich die Zugriffsberechtigung ausdehnt, bzw. wie viele übergeordnete Ebenen geprüft werden, wenn eine URL aufgerufen wird.
Der Konfigurationsschlüssel ist initial deaktiviert (ungültig).
Wenn aktiviert (gültig): Agenten, welche als Verantwortliche am Ticket gesetzt sind, können auf das Ticket zugreifen, auch wenn sie nicht die entsprechenden Basis-Berechtigungen (z. B. auf das Team) haben.
Wichtig
Deaktivieren Sie zuvor den SysConfig-Schlüssel , da die Konfigurationsschlüssel sonst miteinander konkurrieren würden.
Anmerkung
Diese Konfiguration wirkt sich nur auf Basis-Berechtigungen aus.