ACLs OTOBO Znuny

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

Concepts et Valeur Métier : Pourquoi les ACLs 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 ACLs.

1. Concepts et Valeur Métier

Les ACLs définissent quelles actions les agents et les clients peuvent effectuer dans le système de tickets – de manière automatisée et contextuelle.

Sécurité : Protégez les fonctions sensibles (par ex. fermeture de ticket) contre une utilisation non autorisée.
Utilisabilité : Masquez dynamiquement les boutons ou menus non pertinents pour ne pas surcharger l'utilisateur.
Automatisation : Contrôlez les flux de tickets (priorisation, escalade, assignation) directement via des règles ACL, sans code supplémentaire.
Maintenabilité : Exportez, importez et versionnez les ACLs de manière centralisée – idéal pour les environnements multi-instances.

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

Basées sur les rôles : Assignation basée sur les rôles ou groupes d'agents (par ex. Admin vs Agent de support).
Basées sur les critères : Contrôle par attributs de ticket (Queue, Statut, Priorité, DynamicFields, CustomerID).

La combinaison des deux approches permet des règles précises, par exemple : « Seuls les agents seniors déplacent 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 clés :

Composant	Tâche
Kernel::System::ACL::DB::ACL	Backend Perl : Persiste et charge les ACLs 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 quelles ACLs sont nouvelles ou modifiées (sync_state), pour déclencher les déploiements
ZZZACL.pm	Fichier Perl généré qui, lors du déploiement, fournit toutes les ACLs validées dans les modules de ticket

perl

# Exemple : Sérialisation YAML avant insertion en base de données
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 ACLs – pour ne pas se bloquer lui-même.

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 de l'interface utilisateur (boutons, champs) sont affichés ou masqués (Possible, PossibleAdd, PossibleNot) ou quelles actions sont exécutées (changement de statut/queue).

Exemples d'options Match :

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

Exemples d'options Action :

Possible : Autorise uniquement certaines queues ou statuts (liste blanche).
PossibleAdd : Ajoute des valeurs supplémentaires dans une sélection limitée.
PossibleNot : Supprime certains boutons (par ex. AgentTicketClose) de l'interface utilisateur.

4. Paramètres SysConfig importants

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

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

Astuce : Adaptez ACLKeysLevel* pour ne peupler l'interface ACL qu'avec des entrées pertinentes.

Évaluation, Stop-on-Match et Performance

L'évaluation des ACLs (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 effectue une action (par ex. clic sur un bouton), OTOBO parcourt la liste de toutes les ACLs actives, triées selon leur clé de tri (Nom ou ID). Le processus suivant montre le processus de vérification et d'exécution :

Match (ConfigMatch) : Ici, des critères tels que la Queue, le Statut, la Priorité ou les DynamicFields sont vérifiés.
Change (ConfigChange) : Définit quels éléments de l'interface utilisateur sont supprimés ou ajoutés (Possible, PossibleAdd, PossibleNot) ou quelles actions automatiques sont effectuées (changement de Queue/Statut).
StopAfterMatch : S'il est défini sur 1, le traitement s'arrête après la première ACL correspondante.

À retenir : Un StopAfterMatch correctement défini empêche les ACLs suivantes de déclencher des changements 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 ACLs sont vérifiées – nécessaire si plusieurs ACLs 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'ACLs peut prolonger les temps de chargement des formulaires de tickets. Ces mesures aident à améliorer les performances :

Ajuster CacheTTL : Dans SysConfig sous ACL::CacheTTL (par ex. 3600 s), vous définissez combien de temps 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 évite les vérifications répétées.
Réduction des règles : Supprimez les ACLs obsolètes ou dupliquées et regroupez les règles similaires.
Optimiser la séquence : Placez les ACLs fréquemment correspondantes au début de la liste.
Champs indexés : Utilisez des index de base de données pour les DynamicFields et autres propriétés fréquemment interrogées.

xml


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

Maintenance et Bonnes Pratiques

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

Configuration du débogage

xml


<Setting ID="TicketACL::Debug::Enabled">
    <Group>Core::Ticket::ACL</Group>
    <Value>1</Value>
    <Description>Activer le débogage des 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 du 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 des environnements vastes et distribués.

Exemples pratiques, Gouvernance et Référence

Dans cette partie finale de l'article, nous montrons comment utiliser les ACLs dans OTOBO de manière pratique à travers des scénarios concrets. Ensuite, nous abordons les méthodes de gouvernance éprouvées et fournissons des références supplémentaires.

Exemples pratiques

1. Priorisation automatique dans la queue "Alarm"

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

yaml

- 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 Action Change ACL : Changement de queue et ajout de bouton

2. Protection contre l'escalade pour les tickets à priorité "très haute"

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

yaml

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

Protection contre l'escalade Change ACL : Masquer le bouton Fermer

3. Restriction de l'interface utilisateur par queue

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

yaml

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

Supprimer le statut Change ACL : 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.

yaml

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

Restreindre le processus client Change ACL : Masquer le bouton Déplacer 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 assignés aux agents seniors.

yaml

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

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

Gouvernance et Documentation

Mesure	Description
Convention de nommage	Préfixes numériques (par ex. `100-`, `200-`) pour le tri et la clarté.
Journal des modifications	Enregistrez `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 ACLs en YAML et versionnez-les dans Git ou un outil de documentation.
Tests	Validez les ACLs dans un environnement de test avec des tickets de test spécifiques.

Références supplémentaires

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

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

ACLs OTOBO Znuny ​

1. Concepts et Valeur Métier ​

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

2. Aperçu de l'Architecture ​

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

4. Paramètres SysConfig importants ​

Évaluation, Stop-on-Match et Performance ​

Cycle d'évaluation ​

Stratégies Stop-on-Match ​

Optimisation des performances ​

Maintenance et Bonnes Pratiques ​

Configuration du débogage ​

Exemples pratiques, Gouvernance et Référence ​

Exemples pratiques ​

1. Priorisation automatique dans la queue "Alarm" ​

2. Protection contre l'escalade pour les tickets à priorité "très haute" ​

3. Restriction de l'interface utilisateur par queue ​

4. Restriction du processus client ​

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

Gouvernance et Documentation ​

Références supplémentaires ​

ACLs OTOBO Znuny

1. Concepts et Valeur Métier

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

2. Aperçu de l'Architecture

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

4. Paramètres SysConfig importants

Évaluation, Stop-on-Match et Performance

Cycle d'évaluation

Stratégies Stop-on-Match

Optimisation des performances

Maintenance et Bonnes Pratiques

Configuration du débogage

Exemples pratiques, Gouvernance et Référence

Exemples pratiques

1. Priorisation automatique dans la queue "Alarm"

2. Protection contre l'escalade pour les tickets à priorité "très haute"

3. Restriction de l'interface utilisateur par queue

4. Restriction du processus client

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

Gouvernance et Documentation

Références supplémentaires