OTOBO Znuny ACL's

Toegangscontrolelijsten (ACL's) in OTOBO vormen de basis van een robuust permissiebeheer. In dit subonderwerp leert u:

1. Concepten en Business Value: Waarom ACL's onmisbaar zijn.
2. Architectuur Overzicht: Hoe het ACL-subsysteem intern is opgebouwd.
3. Match vs. Action: Basisstructuur van een ACL.
4. Systeemconfiguraties: Belangrijke SysConfig-instellingen rondom ACL's.

---

1. Concepten & Business Value

ACL's definiëren welke acties agenten en klanten mogen uitvoeren in het ticketsysteem – geautomatiseerd en contextgevoelig.

• Beveiliging: Bescherm gevoelige functies (bijv. Ticket sluiten) tegen ongeautoriseerd gebruik.
• Bruikbaarheid: Verberg irrelevante knoppen of menu's dynamisch om de gebruiker niet te overbelasten.
• Automatisering: Stuur ticketworkflows (prioritering, escalatie, toewijzing) direct via ACL-regels, zonder extra code.
• Onderhoudbaarheid: Exporteer, importeer en versieer ACL's centraal – ideaal voor multi-instance omgevingen.

1.1 Rol- en Criteriumgebaseerde ACL's

• Rolgebaseerd: Toewijzing op basis van agentrollen of groepen (bijv. Admin vs. Support Agent).
• Criteriumgebaseerd: Sturing via ticketattributen (Queue, Status, Prioriteit, DynamicFields, CustomerID).

Combinatie van beide benaderingen maakt nauwkeurige regels mogelijk, bijv.: "Alleen Senior Agenten verplaatsen tickets met prioriteit > 3 naar de ontwikkelingsqueue."

---

2. Architectuur Overzicht

Het OTOBO ACL-subsysteem is verdeeld over meerdere kerncomponenten:

Component	Taak
Kernel::System::ACL::DB::ACL	Perl-backend: Persisteert en laadt ACL's uit de database
Kernel::System::YAML	Serialiseert config_match & config_change als YAML-tekst
Kernel::System::Cache	Cachet ACL-verzoeken met TTL (SysConfig: ACL::CacheTTL)
acl_sync tabel	Logt welke ACL's nieuw zijn of gewijzigd zijn (sync_state), om deployments te triggeren
ZZZACL.pm	Gegenereerd Perl-bestand dat bij deployment alle gevalideerde ACL's in de ticketmodules plaatst

# Voorbeeld: YAML-serialisatie voor 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, ...],
);

Opmerking: Superuser (UserID 1) negeert automatisch alle ACL's – om zichzelf niet buitensluiten.

---

3. Basisstructuur van een ACL: Match vs. Action

Sectie	Taak
Match	Definieert voorwaarden: Ticketattributen (Properties) of DB-waarden (PropertiesDatabase) controleren.
Action	Bepaalt welke UI-elementen (knoppen, velden) worden in- of uitgeschakeld (Possible, PossibleAdd, PossibleNot) of welke acties worden uitgevoerd (Status-/Queue-wisseling).

Voorbeeld Match-opties:

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

Voorbeeld Action-opties:

• Possible: Whitelist, bijv. alleen bepaalde queues of statussen toestaan
• PossibleAdd: Extra waarden toevoegen aan een beperkte selectie
• PossibleNot: Bepaalde knoppen (bijv. AgentTicketClose) uit de UI verwijderen

---

4. Belangrijke SysConfig-instellingen

Bovengenoemde kernelementen worden via SysConfig geconfigureerd:

Sleutel	Beschrijving	Voorbeeldwaarde
ACL::CacheTTL	Cache-levensduur in seconden (backend)	3600
ACLKeysLevel1MatchTicket	Toegestane eerste laag voor Match (Properties, PropertiesDatabase)	Properties, PropertiesDatabase
ACLKeysLevel1ChangeTicket	Toegestane eerste laag voor Change (Possible, PossibleAdd, PossibleNot)	Possible, PossibleAdd, PossibleNot
ACLKeysLevel2::PropertiesTicket	Toegestane Match-sleutels (Queue, State, DynamicField, etc.)	Queue, State, CustomerUser, ...
ACLKeysLevel2::PossibleTicket	Toegestane Change-sleutels (Form, FormStd, Action, Process, Ticket)	Form, FormStd, Action, ...
ACLKeysLevel3::Actions###DefaultTicket	Lijst van alle mogelijke acties in de UI (AgentTicketClose, AgentTicketEmail, ...)	(zie lijst)

Tip: Pas ACLKeysLevel* aan om de ACL-UI alleen met relevante items te vullen.

Evaluatie, Stop-on-Match & Performance

De evaluatie van ACL's (Access Control Lists) bepaalt welke regels worden toegepast wanneer een ticket wordt geladen of een actie wordt uitgevoerd in het ticketsysteem. Een efficiënte configuratie van deze processen en gerichte performance-optimalisaties zijn cruciaal om een soepele en schaalbare agentinterface te garanderen.

Evaluatiecyclus

Telkens wanneer een agent een ticket opent of een actie (bijv. knopklik) uitvoert, doorloopt OTOBO de lijst van alle actieve ACL's, geordend op hun sorteersleutel (naam of ID). Het volgende proces toont het controle- en uitvoeringsproces:

• Match (ConfigMatch): Hier worden criteria zoals Queue, Status, Prioriteit of DynamicFields gecontroleerd.
• Change (ConfigChange): Definieert welke UI-elementen worden verwijderd of toegevoegd (Possible, PossibleAdd, PossibleNot) of welke automatische acties plaatsvinden (Queue-/Statuswijziging).
• StopAfterMatch: Indien ingesteld op 1, stopt de verwerking na de eerste passende ACL.

Onthouden: Een correct ingestelde StopAfterMatch voorkomt dat volgende ACL's onbedoelde wijzigingen veroorzaken.

Stop-on-Match Strategieën

Optie	Effect
StopAfterMatch=1	Zodra een ACL matcht, wordt geen enkele andere meer gecontroleerd – ideaal voor exclusieve regels.
StopAfterMatch=0	Alle ACL's worden gecontroleerd – nodig als meerdere ACL's onafhankelijk van elkaar moeten ingrijpen.

Tip: Numerieke voorvoegsels (bijv. 100-, 200-) in de ACL-naam sturen de natuurlijke sortering en daarmee de prioriteit van kritisch belangrijke regels.

Performance Optimalisatie

Een grote set aan ACL's kan de laadtijden van ticketformulieren verlengen. Deze maatregelen helpen de performance te verhogen:

1. CacheTTL aanpassen: In SysConfig onder ACL::CacheTTL (bijv. 3600 s) bepaalt u hoe lang geladen ACL-definities in de cache blijven.
2. Preselection-cache activeren: De module TicketACL::ACLPreselection vult vooraf geselecteerde opties en bespaart herhaalde controles.
3. Regelreductie: Verwijder verouderde of dubbele ACL's en bundel vergelijkbare regels.
4. Sequentie optimaliseren: Plaats veelvoorkomende ACL's aan het begin van de lijst.
5. Geïndexeerde velden: Gebruik DB-indexen voor DynamicFields en andere veel opgevraagde properties.

<Setting ID="ACL::CacheTTL">
    <Group>Core::Ticket::ACL</Group>
    <Value>3600</Value>
    <Description>Cache-levensduur voor DB-ACL-backends in seconden.</Description>
</Setting>

Onderhoud & Best Practices

Praktijk	Nut
YAML-export	Versieer ACL's in Git om wijzigingen te volgen.
Documentatie	Maak een changelog met tijdstempels, auteur en doel van de ACL.
Regelreview	Regelmatige controle in het team voorkomt overlappingen.
Testomgeving	Valideer nieuwe ACL's met gecontroleerde testtickets.
Log-debugging	Activeer debug-logs (TicketACL::Debug::Enabled) voor gedetailleerde inzichten.

Debugging configureren

<Setting ID="TicketACL::Debug::Enabled">
    <Group>Core::Ticket::ACL</Group>
    <Value>1</Value>
    <Description>ACL-debugging activeren</Description>
</Setting>
<Setting ID="TicketACL::Debug::Filter###00-DefaultTicket.xml">
<Group>Core::Ticket::ACL</Group>
<Value>&lt;OTOBO_TICKET_TicketID&gt;</Value>
<Description>Filter voor debug-uitvoer op Ticket-ID.</Description>
</Setting>

Met deze gerichte strategieën zorgt u ervoor dat uw ACL-infrastructuur in OTOBO zowel krachtig als onderhoudbaar blijft – zelfs in grote, gedistribueerde omgevingen.

Praktijkvoorbeelden, Governance & Referentie

In dit afsluitende artikeldeel tonen we aan de hand van concrete scenario's hoe ACL's in OTOBO praktisch worden ingezet. Vervolgens behandelen we bewezen governance-methoden en verwijzen we naar verdere referenties.

Praktijkvoorbeelden

1. Automatische Prioritering naar de "Alarm"-Queue

Doel: Tickets met prioriteit 5 (zeer hoog) direct naar de queue Alarm verplaatsen en medewerkers notificeren.

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

ACL-basisinformatie en Match-instelling

ACL-Change: Queue-wisseling en knop-toevoeging

---

2. Escalatiebescherming voor "zeer hoog" geprioriteerde tickets

Doel: Voorkomen dat tickets met database-prioriteit 5 worden gesloten.

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

ACL-Change: Sluitknop verbergen

---

3. UI-restrictie per Queue

Doel: In de queue Support mag de statusoptie opgelost niet beschikbaar zijn.

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

ACL-Change: Statusoptie verwijderen

---

4. Klantprocesbeperking

Doel: Klanten mogen hun eigen tickets niet naar andere queues verplaatsen.

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

ACL-Change: Move-knop verbergen voor klanten

---

5. Tijdgebaseerde escalatie na 48 uur

Doel: Tickets die ouder zijn dan 48 uur open zijn, worden automatisch toegewezen aan Senior Agenten.

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

Opmerking: Dit scenario vereist mogelijk een uitbreiding voor tijdgebaseerde match-criteria.

---

Governance & Documentatie

Maatregel	Beschrijving
Naamgevingsconventie	Numerieke voorvoegsels (bijv. 100-, 200-) voor sortering en overzichtelijkheid.
Changelog	Log Name, Comment, ChangeTime en ChangeBy voor elke ACL-wijziging.
Reviewproces	Voer regelmatig reviews uit om overlappingen en conflicten te voorkomen.
Versiebeheer	Exporteer ACL's als YAML en versieer in Git of een documentatietool.
Testen	Valideer ACL's in een testomgeving met specifieke testtickets.

---

Verder Lezen

• ACL-referentie (YAML): Kernel/Config/Files/ZZZACL.pm (gegenereerd)
• SysConfig ACL-Keys: Niveau 1-3-termen voor fijnafstemming (Core::Ticket::ACL)
• DynamicField-documentatie: Koppeling van dynamische velden in ACL's

Met deze praktijkvoorbeelden en governance-aanbevelingen beschikt u nu over de middelen om ACL's in OTOBO veilig, efficiënt en traceerbaar te gebruiken.