ACLs OTOBO

Les listes de contrôle d’accès (ACL) dans OTOBO constituent le fondement d’une gestion des droits robuste. Dans ce sous-thème, vous apprendrez :

Concepts et Business Value : Pourquoi les ACL sont indispensables.
Aperçu de l’architecture : Comment le sous-système ACL est structuré en interne.
Match vs. Action : Structure de base d’une ACL.
Configurations système : Paramètres SysConfig importants concernant les ACL.

1. Concepts & Business Value

Les ACL définissent les actions que les agents et les clients peuvent effectuer dans le système de tickets – de manière automatisée et sensible au contexte.

Sécurité : Protégez les fonctions sensibles (par ex. la fermeture de tickets) contre toute utilisation non autorisée.
Usability : Masquez dynamiquement les boutons ou menus non pertinents afin de ne pas surcharger l’utilisateur.
Automatisation : Gérez les flux de tickets (priorisation, escalade, attribution) directement via des règles ACL, sans code supplémentaire.
Maintenabilité : Exportez, importez et versionnez les ACL de manière centralisée – idéal pour les environnements multi-instances.

1.1 ACL basées sur les rôles et les critères

Basées sur les rôles : Attribution en fonction des rôles d’agent ou des groupes (par ex. Admin vs. Support-Agent).
Basées sur les critères : Contrôle via les attributs de ticket (Queue, Status, Priority, DynamicFields, CustomerID).

La combinaison des deux approches permet des règles précises, par ex. : « Seuls les agents seniors peuvent déplacer les tickets avec une priorité > 3 vers la queue de développement. »

2. Aperçu de l’architecture

Le sous-système ACL d’OTOBO est réparti sur plusieurs composants principaux :

Composant	Tâche
Kernel::System::ACL::DB::ACL	Backend Perl : persiste et charge les ACL depuis la base de données
Kernel::System::YAML	Sérialise `config_match` & `config_change` en texte YAML
Kernel::System::Cache	Met en cache les requêtes ACL avec TTL (SysConfig : `ACL::CacheTTL`)
Table acl_sync	Journalise les ACL nouvelles ou modifiées (sync_state) pour déclencher les déploiements
ZZZACL.pm	Fichier Perl généré qui met à disposition toutes les ACL validées dans les modules de tickets lors du déploiement

# Exemple : Sérialisation YAML avant l'insertion en DB
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, ...],
);

Remarque : Le superutilisateur (UserID 1) ignore automatiquement toutes les ACL – afin de ne pas se retrouver bloqué.

3. Structure de base d’une ACL : Match vs. Action

Section	Tâche
Match	Définit les conditions : vérifie les attributs de ticket (Properties) ou les valeurs de la base de données (PropertiesDatabase).
Action	Détermine quels éléments UI (boutons, champs) sont affichés/masqués (Possible, PossibleAdd, PossibleNot) ou quelles actions sont exécutées (changement de statut/queue).

Exemple d’options Match :

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

Exemple d’options Action :

Possible : Liste blanche, par ex. n’autoriser que certaines queues ou statuts
PossibleAdd : Ajouter des valeurs supplémentaires dans une sélection limitée
PossibleNot : Supprimer certains boutons (par ex. AgentTicketClose) de l’UI

4. Paramètres SysConfig importants

Les éléments principaux mentionnés ci-dessus sont configurés via SysConfig :

Clé	Description	Valeur exemple
`ACL::CacheTTL`	Durée de vie du cache en secondes (Backend)	`3600`
`ACLKeysLevel1MatchTicket`	Premier niveau autorisé pour Match (Properties, PropertiesDatabase)	`Properties, PropertiesDatabase`
`ACLKeysLevel1ChangeTicket`	Premier niveau autorisé pour Change (Possible, PossibleAdd, PossibleNot)	`Possible, PossibleAdd, PossibleNot`
`ACLKeysLevel2::PropertiesTicket`	Clés Match autorisées (Queue, State, DynamicField, etc.)	`Queue, State, CustomerUser, ...`
`ACLKeysLevel2::PossibleTicket`	Clés Change autorisées (Form, FormStd, Action, Process, Ticket)	`Form, FormStd, Action, ...`
`ACLKeysLevel3::Actions###DefaultTicket`	Liste de toutes les actions possibles dans l’UI (AgentTicketClose, AgentTicketEmail, …)	(voir liste)

Astuce : Adaptez ACLKeysLevel* pour ne remplir l’UI des ACL qu’avec les entrées pertinentes.

Évaluation, Stop-on-Match & Performance

L’évaluation des ACL (Access Control Lists) détermine quelles règles sont appliquées lorsqu’un ticket est chargé ou qu’une action est exécutée dans le système de tickets. Une configuration efficace de ces processus ainsi que des optimisations de performance ciblées sont cruciales pour garantir une interface agent fluide et évolutive.

Cycle d’évaluation

Chaque fois qu’un agent ouvre un ticket ou exécute une action (par ex. clic sur un bouton), OTOBO parcourt la liste de toutes les ACL actives, classées selon leur clé de tri (nom ou ID). Le déroulement suivant montre le processus de vérification et d’exécution :

flowchart TB
    A[Chargement Ticket / Action Utilisateur] --> B{Liste ACL actives}
    B --> C[Vérification ACL1 : Match ?]
    C -->|oui| D[Exécution de ConfigChange 1]
    C -->|non| E[Vérification ACL2]
    D --> F{StopAfterMatch=1 ?}
    F -->|oui| G[Arrêt : aucune autre ACL]
    F -->|non| E
    E -->|…| H[Vérification ACLN]
    H -->|oui| I[Exécution de ConfigChange N]
    H -->|non| J[Comportement standard]

Match (ConfigMatch) : Ici, les critères tels que la queue, le statut, la priorité ou les DynamicFields sont vérifiés.
Change (ConfigChange) : Définit quels éléments UI sont supprimés ou ajoutés (Possible, PossibleAdd, PossibleNot) ou quelles actions automatiques sont effectuées (changement de queue/statut).
StopAfterMatch : S’il est réglé sur 1, le traitement s’arrête après la première ACL correspondante.

À noter : Un StopAfterMatch correctement défini empêche les ACL suivantes de déclencher des modifications involontaires.

Stratégies Stop-on-Match

Option	Effet
StopAfterMatch=1	Dès qu’une ACL correspond, aucune autre n’est vérifiée – idéal pour les règles exclusives.
StopAfterMatch=0	Toutes les ACL sont vérifiées – nécessaire si plusieurs ACL doivent intervenir indépendamment.

Astuce : Les préfixes numériques (par ex. 100-, 200-) dans le nom de l’ACL contrôlent le tri naturel et donc la priorité des règles critiques.

Optimisation des performances

Un grand ensemble d’ACL peut augmenter les temps de chargement des formulaires de tickets. Ces mesures aident à augmenter les performances :

Adapter CacheTTL : Dans SysConfig sous ACL::CacheTTL (par ex. 3600 s), vous définissez la durée pendant laquelle les définitions d’ACL chargées restent dans le cache.
Activer le cache de présélection : Le module TicketACL::ACLPreselection remplit les options présélectionnées à l’avance et économise des vérifications répétées.
Réduction des règles : Supprimez les ACL obsolètes ou en double et regroupez les règles similaires.
Optimiser la séquence : Placez les ACL qui correspondent fréquemment au début de la liste.
Champs indexés : Utilisez des index DB pour les DynamicFields et autres propriétés fréquemment interrogées.

<Setting ID="ACL::CacheTTL">
    <Group>Core::Ticket::ACL</Group>
    <Value>3600</Value>
    <Description>Durée de vie du cache pour les backends ACL DB en secondes.</Description>
</Setting>

Maintenance & Best Practices

Pratique	Utilité
Export YAML	Versionnez les ACL dans Git pour suivre les modifications.
Documentation	Créez un journal des modifications avec horodatages, auteur et objectif de l’ACL.
Revue de règles	Une vérification régulière en équipe évite les chevauchements.
Environnement de test	Validez les nouvelles ACL avec des tickets de test contrôlés.
Log-Debugging	Activez les logs de débogage (`TicketACL::Debug::Enabled`) pour des aperçus détaillés.

Configurer le débogage

<Setting ID="TicketACL::Debug::Enabled">
    <Group>Core::Ticket::ACL</Group>
    <Value>1</Value>
    <Description>Activer le débogage ACL</Description>
</Setting>
<Setting ID="TicketACL::Debug::Filter###00-DefaultTicket.xml">
<Group>Core::Ticket::ACL</Group>
<Value>&lt;OTOBO_TICKET_TicketID&gt;</Value>
<Description>Filtre pour les sorties de débogage sur l'ID de ticket.</Description>
</Setting>

Grâce à ces stratégies ciblées, vous vous assurez que votre infrastructure ACL dans OTOBO reste performante et maintenable – même dans de grands environnements distribués.

Exemples pratiques, Gouvernance & Référence

Dans cette dernière partie de l’article, nous montrons à l’aide de scénarios concrets comment les ACL sont utilisées dans OTOBO. Ensuite, nous aborderons les méthodes de gouvernance éprouvées et renverrons vers des références complémentaires.

Exemples pratiques

1. Priorisation automatique dans la queue “Alarm”

Objectif : Déplacer immédiatement les tickets avec une priorité 5 (très haute) dans la queue Alarm et notifier le responsable.

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

Paramètres de base Données de base de l’ACL et paramètre Match

Paramètres d'action ACL-Change : Changement de queue et ajout de bouton

2. Protection contre l’escalade pour les tickets de priorité “très haute”

Objectif : Empêcher la fermeture des tickets ayant une priorité de base de données 5.

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

Protection contre l'escalade ACL-Change : Masquer le bouton Close

3. Restriction UI par queue

Objectif : Dans la queue Support, l’option de statut résolu ne doit pas être disponible.

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

Supprimer le statut ACL-Change : Supprimer l’option de statut

4. Restriction du processus client

Objectif : Les clients ne doivent pas pouvoir déplacer leurs propres tickets vers d’autres queues.

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

Restreindre le processus client ACL-Change : Masquer le bouton Move pour les clients

5. Escalade basée sur le temps après 48 heures

Objectif : Les tickets ouverts depuis plus de 48 heures sont automatiquement attribués aux agents seniors.

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

Remarque : Ce scénario nécessite éventuellement une extension pour les critères de correspondance basés sur le temps.

Gouvernance & Documentation

Mesure	Description
Convention de nommage	Préfixes numériques (par ex. `100-`, `200-`) pour le tri et la clarté.
Changelog	Journalisez `Name`, `Comment`, `ChangeTime` et `ChangeBy` pour chaque modification d’ACL.
Processus de revue	Effectuez des revues régulières pour éviter les chevauchements et les conflits.
Versionnement	Exportez les ACL en YAML et versionnez-les dans Git ou un outil de documentation.
Test	Validez les ACL dans un environnement de test avec des tickets de test spécifiques.

Références complémentaires

Référence ACL (YAML) : Kernel/Config/Files/ZZZACL.pm (généré)
Clés ACL SysConfig : Termes de niveau 1 à 3 pour un contrôle fin (Core::Ticket::ACL)
Documentation DynamicField : Intégration de champs dynamiques dans les ACL

Avec ces exemples pratiques et recommandations de gouvernance, vous disposez désormais des outils nécessaires pour exploiter les ACL dans OTOBO de manière sécurisée, efficace et traçable.