Access Control Lists (ACL)¶

Die Arbeit mit Tickets kann zu einer verwirrenden Aufgabe werden. Es gibt viele Möglichkeiten, Tickets zu bearbeiten oder zu schließen, auch wenn sie im aktuellen Zustand eines Tickets oder aufgrund der Rolle des aktuellen Agenten nicht benötigt werden. Das Ausblenden nicht benötigter Einträge bereinigt die Menüleiste und erleichtert die Arbeit. Das Ausblenden von Werten aus Dynamischen Feldern oder Queues verringert die Wahrscheinlichkeit von menschlichen Fehlern.

OTOBO verwendet Zugriffskontrolllisten (Access Control Lists, ACL), um Agenten und Kundennutzer auf Ticket-Optionen so einzuschränken, das nur korrekte und sinnvolle Aktivitäten mit einem Ticket möglich sind. OTOBO-Administratoren können auf einfache Weise ACLs in der grafischen Benutzeroberfläche generieren, um bspw. das Schließen von Tickets zu verhindern, bis bestimmte Anforderungen erfüllt sind oder um zu verhindern, dass Tickets in Queues verschoben werden, bevor definierte Informationen hinzufügen wurden etc.

Verwenden Sie diese Ansicht, um ACLs im System zu verwalten. Eine OTOBO-Neuinstallation beinhaltet standardmäßig keine konfigurierten ACLs. Die Ansicht zur Verwaltung der ACLs ist im Modul Access Control Lists (ACL) in der Gruppe Prozesse & Automatisierung verfügbar.

ACL-Verwaltung

Access Control Lists verwalten¶

Bemerkung

Wenn Sie Access Control Lists erstellen, beachten Sie bitte, dass diese in alphabetischer Reihenfolge ausgeführt, so wie in der Übersicht angezeigt, ausgeführt werden.

Warnung

ACL-Beschränkungen werden für den „Superuser“-Account (UserID1) ignoriert.

So erstellen Sie eine neue ACL:

Klicken Sie in der linken Seitenleiste auf die Schaltfläche Neue ACL erstellen.
Füllen Sie die Pflichtfelder aus.
Klicken Sie auf die Schaltfläche Speichern.
Sie werden zur Ansicht ACL bearbeiten weitergeleitet, um die ACL-Struktur zu bearbeiten.

Neue ACL erstellen

So bearbeiten Sie eine ACL:

Klicken Sie in der Liste mit den ACLs auf die ACL, die Sie bearbeiten möchten.
Bearbeiten Sie die Felder in der ACL-Struktur.
Klicken Sie auf die Schaltfläche Speichern oder Speichern und abschließen.
Alle ACLs in Betrieb nehmen.

ACL-Struktur bearbeiten

So löschen Sie eine ACL:

Klicken Sie in der Liste mit den ACLs auf eine ACL.
Setzen Sie die Option Gültigkeit auf ungültig oder temporär ungültig.
Klicken Sie auf die Schaltfläche Speichern. In der Seitenleiste erscheint eine neue Schaltfläche Ungültige ACL löschen.
Klicken Sie auf die Schaltfläche Ungültige ACL löschen.
Klicken Sie auf die Schaltfläche Löschen im Dialog ACL löschen.
Alle ACLs in Betrieb nehmen.

Warnung

ACLs werden in die Datei ZZZZACL.pm im Perl-Format geschrieben. Ohne Inbetriebnahme befinden sich alle ACLs immer noch in dieser Cache-Datei, auch wenn sie gelöscht werden oder die Option Gültigkeit auf ungültig oder ungültig - temporär gesetzt ist. Vergessen Sie nicht, die ACLs nach Änderungen in Betrieb zu nehmen.

So nehmen Sie alle ACLs in Betrieb:

Klicken Sie in der linken Seitenleiste auf die Schaltfläche ACLs in Betrieb nehmen.

Bemerkung

Neue oder geänderte ACLs müssen in Betrieb genommen werden, damit sie einen Einfluss auf das Verhalten des Systems haben. Wenn die Option Gültigkeit auf gültig gesetzt wird, dann wird damit nur angezeigt, welche ACLs in Betrieb genommen werden.

So exportieren Sie alle ACLs:

Klicken Sie in der linken Seitenleiste auf die Schaltfläche ACLs exportieren.
Wählen Sie einen Speicherort auf Ihrem Computer um die „Export_ACL-yml“-Datei zu speichern.

So importieren Sie ACLs:

Klicken Sie in der linken Seitenleiste auf die Schaltfläche Durchsuchen….
Wählen Sie eine zuvor exportierte .yml Datei.
Setzen Sie einen Haken in das Kontrollkästchen Existierende ACLs überschreiben?, wenn Sie die existierenden ACLs überschreiben möchten.
Klicken Sie auf die Schaltfläche ACL-Konfiguration(en) importieren.
Klicken Sie auf die Schaltfläche ACLs in Betrieb nehmen, um die importierten ACLs in Betrieb zu nehmen.

Bemerkung

Wenn dem System mehrere ACLs hinzugefügt wurden, verwenden Sie das Filterfeld, um einen bestimmte ACL zu finden, indem Sie einfach den zu filternden Namen eingeben.

Warnung

Namensänderungen an diesem Objekt sollten mit Sorgfalt durchgeführt werden. Die Prüfung dient nur der Überprüfung bestimmter Einstellungen und ignoriert Dinge, bei denen der Name nicht überprüft werden kann. Einige Beispiele sind Dashboard-Filter, Action Control Lists (ACLs) und Prozesse (Sequenzfluss-Aktionen), um nur einige zu nennen. Gut dokumentierte Einstellungen verhindern Probleme bei Namensänderungen.

ACL-Einstellungen¶

Die folgenden Einstellungen sind verfügbar, wenn Sie diese Ressource hinzufügen oder bearbeiten. Die mit einem Sternchen gekennzeichneten Felder sind Pflichtfelder.

Name *: Der Name der Ressource. In dieses Feld können beliebige Zeichen eingegeben werden, einschließlich Großbuchstaben und Leerzeichen. Der Name wird in der Übersichtstabelle angezeigt.
Kommentar: Fügen Sie dieser Ressource zusätzliche Informationen hinzu. Es wird empfohlen, dieses Feld als Beschreibung der Ressource zur besseren Übersichtlichkeit immer mit einem vollständigen Satz zu füllen, da der Kommentar auch in der Übersichtstabelle angezeigt wird.
Beschreibung: Wie Kommentar, aber hier kann längerer Text hinzugefügt werden.
Stoppen nach Treffer: ACLs werden in alphabetischer Reihenfolge ausgewertet. Diese Einstellung deaktiviert die Auswertung der nachfolgenden ACLs.
Gültigkeit *: Setzt die Gültigkeit dieser Ressource. Jede Ressource kann nur in OTOBO verwendet werden, wenn dieses Feld auf gültig gesetzt ist. Wenn Sie dieses Feld auf ungültig oder ungültig-temporär setzen, wird die Nutzung der Ressource deaktiviert.

ACL-Struktur bearbeiten¶

Die ACL-Definition kann in zwei große Teile aufgeteilt werden, Filterbedingungen und Werte ändern. In den entsprechenden Abschnitten enthalten die ACLs Attribute, die erfüllt sein müssen, um die ACL nutzen zu können. Wenn die in der ACL definierten Attribute nicht mit den gesendeten Attributen übereinstimmen, hat die ACL keine Auswirkungen, aber jede andere übereinstimmende ACL. Der Abschnitt „Werte ändern“ enthält die Regeln, die zutreffen sollen, wenn die Filterbedingungen erfüllt sind.

Filterbedingungen¶

Properties: Dieser Abschnitt enthält passende Optionen, die spontan geändert werden können. Beispielsweise ändern sich während einer Ticket-Erstellungszeit die Daten des Tickets dynamisch, wenn der Agent die Informationen einstellt. Wenn eine ACL so eingestellt ist, dass sie mit einem Ticket-Attribut übereinstimmt, dann ist die ACL nur dann aktiv, wenn das passende Attribut ausgewählt ist, und kann andere Ticket-Attribute reduzieren. Sobald ein anderer Wert ausgewählt wird, hat die ACL keinen Einfluss.
PropertiesDatabase: Dieser Abschnitt ähnelt Properties, nimmt aber keine Änderungen an Ticket-Attributen vor, die nicht in der Datenbank gespeichert sind. Das bedeutet, dass das Ändern eines Attributs ohne Bestätigung keinen Effekt hat. Dieser Abschnitt wird nicht für die Erstellung von Tickets verwendet (da Tickets noch nicht in der Datenbank angelegt sind).

Wertänderungen¶

Possible: Dieser Abschnitt dient dazu, die zu reduzierenden Daten auf die in diesem Abschnitt eingestellten Elemente zurückzusetzen.
PossibleAdd: In diesem Abschnitt werden fehlende Elemente hinzugefügt, die in anderen ACLs reduziert wurden. Dieser Abschnitt wird nur in Verbindung mit anderen ACLs verwendet, die Possibles oder PossiblesNot-Abschnitte haben.
PossibleNot: In diesem Abschnitt werden bestimmte Elemente aus den aktuellen Daten entfernt. Er kann einzeln oder zusammen mit anderen ACLs verwendet werden, die einen Possible oder PossibleAdd`-Abschnitt haben.

Modifikator¶

Um die Entwicklung von ACLs einfacher und leistungsfähiger zu machen, gibt es eine Reihe von so genannten Modifikatoren für die Attribute der einzelnen Abschnitte. Diese Modifikatoren werden im Folgenden erläutert:

[Not]: Dieser Modifikator wird genutzt, um einen Wert zu negieren, bspw. [Not]2 niedrig. Das bedeutet für Ticket-Prioritäten dasselbe wie: 1 sehr niedrig, 3 normal, 4 hoch, 5 sehr hoch
[RegExp]: Es wird verwendet, um einen regulären Ausdruck zu definieren, um mehrere Werte abzugleichen, z.B. [RegExp]niedrig. Das bedeutet für Ticket-Prioritäten dasselbe wie 1 sehr niedrig, 2 niedrig.
[regexp]: Ähnlich zu [RegExp] aber unabhängig von Groß- und Kleinschreibung.
[NotRegExp]: Negierter regulärer Ausdruck, bspw. [NotRegExp]niedrig. Das bedeutet für Ticket-Prioritäten dasselbe wie 3 normal, 4 hoch, 5 sehr hoch
[Notregexp]: Ähnlich zu [NotRegExp] aber unabhängig von Groß- und Kleinschreibung.

ACL-Beispiele¶

Ticket nach Priorität in die Queue verschieben¶

Dieses Beispiel zeigt Ihnen, wie Sie nur die Tickets in eine Queue verschieben, die eine Priorität von 5 sehr hoch haben.

Zuerst benötigen wir einen Namen. In diesem Beispiel: 100-Example-ACL. Beachten Sie, dass ACLs vor der Ausführung nummerisch sortiert werden und wählen Sie den Namen mit Bedacht. Die Felder „Kommentar“ und „Beschreibung“ sind optional.

100-Example-ACL - -Basis-Einstellungen

Zweitens haben Sie einen Eigenschaften-Bereich, der ein Filter für Ihre Tickets ist. Alle hier definierten Kriterien werden auf ein Ticket angewendet, um festzustellen, ob die ACL angewendet werden muss oder nicht. In unserem Beispiel stimmt ein Ticket überein, wenn es sich in der Warteschlange Raw befindet und die Priorität 5 sehr hoch hat. Dies wird auch durch Änderungen in der Form beeinflusst (z. B. wenn das Ticket die Warteschlange Raw ist und zu diesem Zeitpunkt eine Priorität 3 normal hatte, wird die ACL nicht übereinstimmen. Wenn aber die Dropdown-Liste für die Priorität ausgewählt wird und die Priorität auf 5 sehr hoch geändert wird, dann wird die ACL angewendet).

100-Example-ACL - Filterbedingungen

Abschließend definiert ein Abschnitt Possible Änderungen an den Ansichten. In diesem Fall kann aus den verfügbaren Qeues nur die Queue Alert in einer Ticket-Erstellungsansicht ausgewählt werden.

100-Example-ACL - Werte ändern

Bemerkung

Vergessen Sie nicht, die Gültigkeit auf gültig zu setzen, bevor Sie eine neue ACL in Betrieb nehmen.

Ticket in Queue verschieben basierend auf der Priorität, die in der Datenbank gespeichert ist¶

Dieses Beispiel ist dem ersten sehr ähnlich, aber in diesem Fall filtert die ACL nur Tickets in der Queue Raw und mit einer Priorität 5 sehr hoch, wie sie in der Datenbank gespeichert sind. Diese Art von ACLs berücksichtigt keine Änderungen, die während der Ticket-Erstellung vorgenommen werden. Erst, wenn es in der Datenbank aktualisiert wird.

101-Example-ACL

Schließen eines Tickets in einer Queue deaktivieren und „Schließen“-Schaltfläche verbergen¶

Dieses Beispiel zeigt, wie man die Möglichkeit zum Schließen von Tickets in der Queue Raw deaktiviert und die Schaltfläche „Schließen“ verbirgt. Es ist möglich, ein Ticketfeld (Status) mit mehr als einem möglichen Wert zu filtern. Es ist auch möglich, die Aktionen zu begrenzen, die für ein bestimmtes Ticket ausgeführt werden können. In diesem Fall kann das Ticket nicht geschlossen werden.

102-Example-ACL

Status entfernen¶

Dieses Beispiel zeigt, wie es möglich ist, Negativfilter zu definieren (der Zustand erfolgreich geschlossen wird entfernt). Sie können auch sehen, dass das nicht definieren von Filtereigenschaften für ein Ticket mit jedem Ticket übereinstimmt, d. h. die ACL wird immer angewendet. Dies kann nützlich sein, wenn Sie bestimmte Werte standardmäßig ausblenden und nur unter besonderen Umständen (z. B. wenn sich der Agent in einer bestimmten Gruppe befindet) aktivieren wollen.

103-Example-ACL

Die Verwendung von regulären Ausdrücken¶

Dieses Beispiel zeigt Ihnen, wie Sie reguläre Ausdrücke für übereinstimmende Tickets und zum Filtern der verfügbaren Optionen verwenden können. Diese ACL zeigt nur Hardware-Services für Tickets an, die in Queues erstellt werden, die mit HW beginnen.

104-Example-ACL

Prozess für Kunde nicht erlauben¶

Dieses ACL beschränkt den Prozess P14 im externen Interface für die Kundennummer TheCustomerID.

105-Example-ACL

Disallow Standard Reply Function For Customers in Process¶

This ACL prohibits using the reply button in CustomerTicketZoom if the ticket is a process ticket of the process with entity ID Process-0123456789abcdef.

106-Example-ACL

ACL-Referenz¶

Properties, keys and values that can be used in ACLs are highly dependent on the OTOBO installation. For example the possibilities can be extended by installing extension modules, as well as it can depend on the customer user mapping set in Config.pm. Therefore it is not possible to provide a full ACL reference, that contains all settings.

Für Eigenschaften, Schlüssel und Werte, die in ACLs genutzt werden können, schauen Sie sich die Beispiel-ACL im YAML-Format an.

---
- ChangeBy: root@localhost
  ChangeTime: 2019-01-07 10:42:59
  Comment: ACL Reference.
  ConfigMatch:
    Properties:
      # Match properties (current values from the form).
      CustomerUser:
        UserLogin:
        - some login
        UserCustomerID:
        - some customer ID
        Group_rw:
        - some group
      DynamicField:
        # Names must be in DynamicField_<field_name> format.
        # Values for dynamic fields must always be the untranslated internal
        #   data keys specified in the dynamic field definition and not the
        #   data values shown to the user.
        DynamicField_Field1:
        - some value
        DynamicField_OtherField:
        - some value
        DynamicField_TicketFreeText2:
        - some value
        # more dynamic fields
      Frontend:
        Action:
        - AgentTicketPhone
        - AgentTicketEmail
        - ...
        - CustomerTicketZoomReply
        Endpoint:
        - ExternalFrontend::PersonalPreferences
        - ExternalFrontend::ProcessTicketCreate
        - ExternalFrontend::ProcessTicketNextStep
        - ExternalFrontend::TicketCreate
        - ExternalFrontend::TicketDetailView
        - ...
      Owner:
        UserLogin:
        - some login
        Group_rw:
        - some group
        Role:
        - admin
        # more owner attributes
      Priority:
        ID:
        - some ID
        Name:
        - some name
        # more priority attributes
      Process:
        ProcessEntityID:
        # the process that the current ticket is part of
        - Process-9c378d7cc59f0fce4cee7bb9995ee3eb
        ActivityEntityID:
        # the current activity of the ticket
        - Activity-f8b2fdebe54eeb7b147a5f8e1da5e35c
        ActivityDialogEntityID:
        # the current activity dialog that the agent/customer is using
        - ActivityDialog-aff0ae05fe6803f38de8fff6cf33b7ce
      Queue:
        Name:
        - Raw
        QueueID:
        - some ID
        GroupID:
        - some ID
        Email:
        - some email
        RealName:
        - OTOBO System
        # more queue attributes
      Responsible:
        UserLogin:
        - some login
        Group_rw:
        - some group
        Role:
        - admin
        # more responsible attributes
      Service:
        ServiceID:
        - some ID
        Name:
        - some name
        ParentID:
        - some ID
        # more service attributes
      SLA:
        SLAID:
        - some ID
        Name:
        - some name
        Calendar:
        - some calendar
        # more SLA attributes
      State:
        ID:
        - some ID
        Name:
        - some name
        TypeName:
        - some state type name
        TypeID:
        - some state type ID
        # more state attributes
      Ticket:
        Queue:
        - Raw
        State:
        - new
        - open
        Priority:
        - some priority
        Lock:
        - lock
        CustomerID:
        - some ID
        CustomerUserID:
        - some ID
        Owner:
        - some owner
        DynamicField_Field1:
        - some value
        DynamicField_MyField:
        - some value
        # more ticket attributes
      Type:
        ID:
        - some ID
        Name:
        - some name
        # more type attributes
      User:
        UserLogin:
        - some_login
        Group_rw:
        - some group
        Role:
        - admin
    PropertiesDatabase:
      # Match properties (existing values from the database).
      # Please note that Frontend is not in the database, but in the framework.
      # See section "Properties", the same configuration can be used here.
  ConfigChange:
    Possible:
      # Reset possible options (white list).
      # Hide or show Dynamicfields
      # Please just enter the name of the Dynamic Fields, they don't need any prefix.
      Form:
      - SomeDynamicFieldName
      - someOtherDynamicFieldName
      # Hide or show Standard Fields like Article (in the future Queue, Service, etc.)
      FormStd:
      # Hide or show Article in CustomerTicketMessage (including all three: Subject, Body and Attachment)
      - Article
      Action:
      # Possible action options (white list).
      - AgentTicketBounce
      - AgentTicketPhone   # only used to show/hide the Split action
      - AgentLinkObject    # only used to show/hide the Link action
      - ...
      ActivityDialog:
      # Limit the number of possible activity dialogs the agent/customer can use in a process ticket.
      - ActivityDialog-aff0ae05fe6803f38de8fff6cf33b7ce
      - ActivityDialog-429d61180a593414789a8087cc4b3c6f
      - ...
      Endpoint:
      # Limit the functions on external interface.
      - ExternalFrontend::PersonalPreferences
      - ExternalFrontend::ProcessTicketCreate
      - ExternalFrontend::ProcessTicketNextStep
      - ExternalFrontend::TicketCreate
      - ExternalFrontend::TicketDetailView
      - ...
      Process:
      # Limit the number of possible processes that can be started.
      - Process-9c378d7cc59f0fce4cee7bb9995ee3eb
      - Process-12345678901234567890123456789012
      - ...
      Ticket:
      # Possible ticket options (white list).
        Queue:
        - Raw
        - some other queue
        State:
        - some state
        Priority:
        - 5 very high
        DynamicField_Field1:
        - some value
        DynamicField_MyField:
        - some value
        # more dynamic fields
        NewOwner:
        # For ticket action screens, where the Owner is already set.
        - some owner
        OldOwner:
        # For ticket action screens, where the Owner is already set.
        - some owner
        Owner:
        # For ticket create screens, because Owner is not set yet. Please make sure, that you enter "Firstname Lastname".
        - some owner
        SLA:
        - some sla-name
        # more ticket attributes
    PossibleAdd:
       # Add options (white list).
       # See section "Possible", the same configuration can be used here.
    PossibleNot:
       # Remove options (black list).
       # See section "Possible", the same configuration can be used here.
  CreateBy: root@localhost
  CreateTime: 2019-01-07 10:42:59
  Description: This is the long description of the ACL to explain its usage.
  ID: 1
  Name: 200-ACL-Reference
  StopAfterMatch: 0
  ValidID: 3