OTOBO Znuny ACLs

Zugriffskontrolllisten (ACLs) in OTOBO sind das Fundament einer robusten Rechteverwaltung. In diesem Subthema lernen Sie:

Konzepte und Business Value: Warum ACLs unverzichtbar sind.
Architekturüberblick: Wie das ACL-Subsystem intern aufgebaut ist.
Match vs. Action: Grundstruktur einer ACL.
Systemkonfigurationen: Wichtige SysConfig-Einstellungen rund um ACLs.

1. Konzepte & Business Value

ACLs definieren, welche Aktionen Agenten und Kunden im Ticketsystem ausführen dürfen – automatisiert und kontextsensitiv.

Sicherheit: Schützen Sie sensible Funktionen (z. B. Ticket-Schließen) vor unautorisierter Nutzung.
Usability: Blenden Sie irrelevante Buttons oder Menüs dynamisch aus, um den Anwender nicht zu überfrachten.
Automatisierung: Steuern Sie Ticket-Flows (Priorisierung, Eskalation, Zuweisung) direkt über ACL-Regeln, ohne zusätzlichen Code.
Wartbarkeit: Exportieren, importieren und versionieren Sie ACLs zentral – ideal für Multi-Instanz-Umgebungen.

1.1 Rollen- und Kriterien-basierte ACLs

Rollenbasiert: Zuweisung anhand von Agenten-Rollen oder Gruppen (z. B. Admin vs. Support-Agent).
Kriterienbasiert: Steuerung durch Ticketattribute (Queue, Status, Priority, DynamicFields, CustomerID).

Kombination beider Ansätze ermöglicht präzise Regeln, z. B.: „Nur Senior-Agenten verschieben Tickets mit Priorität > 3 in die Entwicklung-Queue.“

2. Architektur-Überblick

Das OTOBO-ACL-Subsystem verteilt sich auf mehrere Kernkomponenten:

Komponente	Aufgabe
Kernel::System::ACL::DB::ACL	Perl-Backend: Persistiert und lädt ACLs aus der Datenbank
Kernel::System::YAML	Serialisiert `config_match` & `config_change` als YAML-Text
Kernel::System::Cache	Cacht ACL-Abfragen mit TTL (SysConfig: `ACL::CacheTTL`)
acl_sync Tabelle	Protokolliert, welche ACLs neu sind oder geändert wurden (sync_state), um Deployments zu triggern
ZZZACL.pm	Generierte Perl-Datei, die beim Deploy alle validierten ACLs in den Ticket-Modulen bereitstellt

perl

# Beispiel: YAML-Serialisierung vor DB-Insert
my $YAML = $Kernel::OM->Get('Kernel::System::YAML');
my $ConfigMatchYAML  = $YAML->Dump(Data => $Param{ConfigMatch});
my $ConfigChangeYAML = $YAML->Dump(Data => $Param{ConfigChange});
$DBObject->Do(
    SQL  => 'INSERT INTO acl (..., config_match, config_change, ...) VALUES (?, ?, ?, ...)',
    Bind => [\$ConfigMatchYAML, \$ConfigChangeYAML, ...],
);

Hinweis: Superuser (UserID 1) ignoriert alle ACLs automatisch – um sich nicht auszusperren.

3. Grundstruktur einer ACL: Match vs. Action

Abschnitt	Aufgabe
Match	Definiert Bedingungen: Ticketattribute (Properties) oder DB-Werte (PropertiesDatabase) prüfen.
Action	Legt fest, welche UI-Elemente (Buttons, Felder) ein-/ausgeblendet werden (Possible, PossibleAdd, PossibleNot) oder welche Aktionen ausgeführt werden (Status-/Queue-Wechsel).

Beispiel Match-Optionen:

Queue, Status, Priority
DynamicField_<Name>, CustomerUser, Owner
Frontend::Module (AgentTicketZoom, CustomerTicketCreate)

Beispiel Action-Optionen:

Possible: Whitelist z. B. nur bestimmte Queues oder Status zulassen
PossibleAdd: Zusätzliche Werte in begrenzter Auswahl hinzufügen
PossibleNot: Bestimmte Buttons (z. B. AgentTicketClose) aus UI entfernen

4. Wichtige SysConfig-Einstellungen

Oben genannte Kernelemente werden über SysConfig konfiguriert:

Schlüssel	Beschreibung	Beispielwert
`ACL::CacheTTL`	Cache-Lebensdauer in Sekunden (Backend)	`3600`
`ACLKeysLevel1MatchTicket`	Erlaubte erste Ebene für Match (Properties, PropertiesDatabase)	`Properties, PropertiesDatabase`
`ACLKeysLevel1ChangeTicket`	Erlaubte erste Ebene für Change (Possible, PossibleAdd, PossibleNot)	`Possible, PossibleAdd, PossibleNot`
`ACLKeysLevel2::PropertiesTicket`	Erlaubte Match-Keys (Queue, State, DynamicField, etc.)	`Queue, State, CustomerUser, ...`
`ACLKeysLevel2::PossibleTicket`	Erlaubte Change-Keys (Form, FormStd, Action, Process, Ticket)	`Form, FormStd, Action, ...`
`ACLKeysLevel3::Actions###DefaultTicket`	Liste aller möglichen Aktionen in der UI (AgentTicketClose, AgentTicketEmail, ...)	(s. Liste)

Tipp: Passen Sie ACLKeysLevel* an, um das ACL-UI nur mit relevanten Einträgen zu bestücken.

Evaluierung, Stop-on-Match & Performance

Die Evaluierung von ACLs (Access Control Lists) bestimmt, welche Regeln angewendet werden, wenn ein Ticket geladen oder eine Aktion im Ticketsystem ausgeführt wird. Eine effiziente Konfiguration dieser Abläufe sowie gezielte Performance-Optimierungen sind entscheidend, um ein flüssiges und skalierbares Agenten-Interface zu gewährleisten.

Evaluierungszyklus

Jedes Mal, wenn ein Agent ein Ticket öffnet oder eine Aktion (z. B. Button-Klick) ausführt, durchläuft OTOBO die Liste aller aktiven ACLs geordnet nach ihrem Sortierschlüssel (Name oder ID). Folgender Ablauf zeigt den Prüf- und Ausführungsprozess:

Match (ConfigMatch): Hier werden Kriterien wie Queue, Status, Priority oder DynamicFields geprüft.
Change (ConfigChange): Definiert, welche UI-Elemente entfernt oder hinzugefügt werden (Possible, PossibleAdd, PossibleNot) oder welche automatischen Aktionen erfolgen (Queue-/Statuswechsel).
StopAfterMatch: Wird auf 1 gesetzt, bricht die Verarbeitung nach der ersten zutreffenden ACL ab.

Merke: Ein korrekt gesetztes StopAfterMatch verhindert, dass nachfolgende ACLs unbeabsichtigte Änderungen auslösen.

Stop-on-Match-Strategien

Option	Wirkung
StopAfterMatch=1	Sobald eine ACL matcht, wird keine weitere überprüft – ideal für exklusive Regeln.
StopAfterMatch=0	Alle ACLs werden geprüft – nötig, wenn mehrere ACLs unabhängig voneinander eingreifen sollen.

Tipp: Nummerische Präfixe (z. B. 100-, 200-) im ACL-Namen steuern die natürliche Sortierung und damit die Priorität kritisch wichtiger Regeln.

Performance-Optimierung

Ein großes Set an ACLs kann die Ladezeiten von Ticketformularen verlängern. Diese Maßnahmen helfen, die Performance zu steigern:

CacheTTL anpassen: In SysConfig unter ACL::CacheTTL (z. B. 3600 s) legen Sie fest, wie lange geladene ACL-Definitionen im Cache verbleiben.
Preselection-Cache aktivieren: Das Modul TicketACL::ACLPreselection füllt vorausgewählte Optionen vorab und spart wiederholte Prüfungen.
Regel-Reduktion: Entfernen Sie veraltete oder doppelte ACLs und bündeln Sie ähnliche Regeln.
Sequenz optimieren: Platzieren Sie häufig zutreffende ACLs an den Anfang der Liste.
Indexierte Felder: Nutzen Sie DB-Indexe für DynamicFields und andere häufig abgefragte Properties.

xml


<Setting ID="ACL::CacheTTL">
    <Group>Core::Ticket::ACL</Group>
    <Value>3600</Value>
    <Description>Cache-Lebensdauer für DB-ACL-Backends in Sekunden.</Description>
</Setting>

Wartung & Best Practices

Praxis	Nutzen
YAML-Export	Versionieren Sie ACLs in Git, um Änderungen nachzuvollziehen.
Dokumentation	Erstellen Sie ein Change-Log mit Zeitstempeln, Autor und Ziel der ACL.
Regel-Review	Regelmäßige Überprüfung im Team verhindert Überschneidungen.
Testumgebung	Validieren Sie neue ACLs mit kontrollierten Testtickets.
Log-Debugging	Aktivieren Sie Debug-Logs (`TicketACL::Debug::Enabled`) für detaillierte Einblicke.

Debugging konfigurieren

xml


<Setting ID="TicketACL::Debug::Enabled">
    <Group>Core::Ticket::ACL</Group>
    <Value>1</Value>
    <Description>ACL-Debugging aktivieren</Description>
</Setting>
<Setting ID="TicketACL::Debug::Filter###00-DefaultTicket.xml">
<Group>Core::Ticket::ACL</Group>
<Value>&lt;OTOBO_TICKET_TicketID&gt;</Value>
<Description>Filter für Debug-Ausgaben auf Ticket-ID.</Description>
</Setting>

Durch diese gezielten Strategien stellen Sie sicher, dass Ihre ACL-Infrastruktur in OTOBO sowohl leistungsfähig als auch wartbar bleibt – selbst in großen, verteilten Umgebungen.

Praxisbeispiele, Governance & Referenz

In diesem abschließenden Artikelteil zeigen wir anhand konkreter Szenarien, wie ACLs in OTOBO praxisnah eingesetzt werden. Anschließend behandeln wir bewährte Governance-Methoden und verweisen auf weiterführende Referenzen.

Praxisbeispiele

1. Automatische Priorisierung in die "Alarm"-Queue

Ziel: Tickets mit Priorität 5 (sehr hoch) sofort in die Queue Alarm verschieben und Bearbeiter benachrichtigen.

yaml

- Name: "100-Auto-Alarm"
  StopAfterMatch: 1
  ValidID: 1
  ConfigMatch:
    Properties:
      Priority:
        ID: [ 5 ]
  ConfigChange:
    PossibleNot:
      Form:
        - ticketCreateQuickClose
    PossibleAdd:
      Form:
        - ticketCreateNotifyOwner
    Action:
      Queue: "Alarm"

Basis-Einstellungen ACL-Grunddaten und Match-Einstellung

Action-Einstellungen ACL-Change: Queue-Wechsel und Button-Add

2. Eskalationsschutz für "sehr hoch" priorisierte Tickets

Ziel: Verhindern, dass Tickets mit Datenbank-Priorität 5 geschlossen werden.

yaml

- Name: "101-No-Close-High"
  StopAfterMatch: 1
  ValidID: 1
  ConfigMatch:
    PropertiesDatabase:
      Priority:
        Name: [ "5" ]
  ConfigChange:
    PossibleNot:
      Action:
        - AgentTicketClose

Eskalationsschutz ACL-Change: Close-Button ausblenden

3. UI-Restriction pro Queue

Ziel: In der Queue Support soll die Statusoption gelöst nicht verfügbar sein.

yaml

- Name: "102-Hide-Resolved-Support"
  ValidID: 1
  ConfigMatch:
    Properties:
      Queue:
        Name: [ "Support" ]
  ConfigChange:
    PossibleNot:
      FormStd:
        - State::resolved

Status entfernen ACL-Change: Status-Option entfernen

4. Kundenprozess-Beschränkung

Ziel: Kunden dürfen eigene Tickets nicht in andere Queues verschieben.

yaml

- Name: "103-Cust-No-Reassign"
  ValidID: 1
  ConfigMatch:
    Properties:
      Frontend:
        Action:
          - CustomerTicketZoomReply
  ConfigChange:
    PossibleNot:
      Action:
        - AgentTicketMove

Kundenprozess beschränken ACL-Change: Move-Button ausblenden für Kunden

5. Zeitbasierte Eskalation nach 48 Stunden

Ziel: Tickets, die älter als 48 Stunden offen sind, werden automatisch an Senior-Agenten zugewiesen.

yaml

- Name: "104-Escalate-48h"
  ValidID: 1
  ConfigMatch:
    Properties:
      Ticket:
        CreateTimeOlderThan: 48h
  ConfigChange:
    Action:
      Owner: "Senior-Agenten"

Hinweis: Dieses Szenario erfordert gegebenenfalls eine Erweiterung für zeitbasierte Match-Kriterien.

Governance & Dokumentation

Maßnahme	Beschreibung
Namenskonvention	Numerische Präfixe (z. B. `100-`, `200-`) für Sortierung und Übersichtlichkeit.
Changelog	Protokollieren Sie `Name`, `Comment`, `ChangeTime` und `ChangeBy` für jede ACL-Änderung.
Review-Prozess	Führen Sie regelmäßig Reviews durch, um Überschneidungen und Konflikte zu vermeiden.
Versionierung	Exportieren Sie ACLs als YAML und versionieren Sie in Git oder einem Dokumentationstool.
Testing	Validieren Sie ACLs in einer Testumgebung mit spezifischen Testtickets.

Weiterführende Referenzen

ACL-Referenz (YAML): Kernel/Config/Files/ZZZACL.pm (generiert)
SysConfig ACL-Keys: Level 1–3-Begriffe zur Feinsteuerung (Core::Ticket::ACL)
DynamicField-Dokumentation: Anbindung dynamischer Felder in ACLs

Mit diesen Praxisbeispielen und Governance-Empfehlungen verfügen Sie nun über das Rüstzeug, um ACLs in OTOBO sicher, effizient und nachvollziehbar zu betreiben.

OTOBO Znuny ACLs ​

1. Konzepte & Business Value ​

1.1 Rollen- und Kriterien-basierte ACLs ​

2. Architektur-Überblick ​

3. Grundstruktur einer ACL: Match vs. Action ​

4. Wichtige SysConfig-Einstellungen ​

Evaluierung, Stop-on-Match & Performance ​

Evaluierungszyklus ​

Stop-on-Match-Strategien ​

Performance-Optimierung ​

Wartung & Best Practices ​

Debugging konfigurieren ​

Praxisbeispiele, Governance & Referenz ​

Praxisbeispiele ​

1. Automatische Priorisierung in die "Alarm"-Queue ​

2. Eskalationsschutz für "sehr hoch" priorisierte Tickets ​

3. UI-Restriction pro Queue ​

4. Kundenprozess-Beschränkung ​

5. Zeitbasierte Eskalation nach 48 Stunden ​

Governance & Dokumentation ​

Weiterführende Referenzen ​

OTOBO Znuny ACLs

1. Konzepte & Business Value

1.1 Rollen- und Kriterien-basierte ACLs

2. Architektur-Überblick

3. Grundstruktur einer ACL: Match vs. Action

4. Wichtige SysConfig-Einstellungen

Evaluierung, Stop-on-Match & Performance

Evaluierungszyklus

Stop-on-Match-Strategien

Performance-Optimierung

Wartung & Best Practices

Debugging konfigurieren

Praxisbeispiele, Governance & Referenz

Praxisbeispiele

1. Automatische Priorisierung in die "Alarm"-Queue

2. Eskalationsschutz für "sehr hoch" priorisierte Tickets

3. UI-Restriction pro Queue

4. Kundenprozess-Beschränkung

5. Zeitbasierte Eskalation nach 48 Stunden

Governance & Dokumentation

Weiterführende Referenzen