OTOBO ACLs

Las listas de control de acceso (ACLs) en OTOBO son la base de una gestión de derechos robusta. En este subtema aprenderá:

Conceptos y Business Value: Por qué las ACL son indispensables.
Resumen de arquitectura: Cómo está estructurado internamente el subsistema de ACL.
Match vs. Action: Estructura básica de una ACL.
Configuraciones del sistema: Ajustes importantes de SysConfig relacionados con las ACL.

1. Conceptos y Business Value

Las ACL definen qué acciones pueden realizar los agentes y clientes en el sistema de tickets, de forma automatizada y sensible al contexto.

Seguridad: Proteja funciones sensibles (p. ej., cerrar tickets) contra el uso no autorizado.
Usabilidad: Oculte dinámicamente botones o menús irrelevantes para no sobrecargar al usuario.
Automatización: Controle los flujos de tickets (priorización, escalado, asignación) directamente mediante reglas ACL, sin código adicional.
Mantenibilidad: Exporte, importe y versione ACLs de forma centralizada, ideal para entornos de múltiples instancias.

1.1 ACL basadas en roles y criterios

Basadas en roles: Asignación según roles de agente o grupos (p. ej., Admin vs. Agente de soporte).
Basadas en criterios: Control mediante atributos de ticket (Queue, Status, Priority, DynamicFields, CustomerID).

La combinación de ambos enfoques permite reglas precisas, p. ej.: “Solo los agentes senior pueden mover tickets con prioridad > 3 a la cola de desarrollo”.

2. Resumen de arquitectura

El subsistema de ACL de OTOBO se distribuye en varios componentes principales:

Componente	Tarea
Kernel::System::ACL::DB::ACL	Backend de Perl: Persiste y carga las ACL desde la base de datos
Kernel::System::YAML	Serializa `config_match` y `config_change` como texto YAML
Kernel::System::Cache	Caché de consultas ACL con TTL (SysConfig: `ACL::CacheTTL`)
Tabla acl_sync	Registra qué ACL son nuevas o han sido modificadas (sync_state) para activar despliegues
ZZZACL.pm	Archivo Perl generado que proporciona todas las ACL validadas en los módulos de tickets al desplegar

# Ejemplo: Serialización YAML antes de insertar en la 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, ...],
);

Nota: El superusuario (UserID 1) ignora todas las ACL automáticamente para evitar quedar bloqueado.

3. Estructura básica de una ACL: Match vs. Action

Sección	Tarea
Match	Define condiciones: verifica atributos de ticket (Properties) o valores de la DB (PropertiesDatabase).
Action	Determina qué elementos de la UI (botones, campos) se muestran/ocultan (Possible, PossibleAdd, PossibleNot) o qué acciones se ejecutan (cambio de estado/cola).

Ejemplo de opciones de Match:

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

Ejemplo de opciones de Action:

Possible: Lista blanca, p. ej., permitir solo ciertas colas o estados
PossibleAdd: Añadir valores adicionales en una selección limitada
PossibleNot: Eliminar botones específicos (p. ej., AgentTicketClose) de la UI

4. Ajustes importantes de SysConfig

Los elementos principales mencionados anteriormente se configuran a través de SysConfig:

Clave	Descripción	Valor de ejemplo
`ACL::CacheTTL`	Tiempo de vida de la caché en segundos (Backend)	`3600`
`ACLKeysLevel1MatchTicket`	Primer nivel permitido para Match (Properties, PropertiesDatabase)	`Properties, PropertiesDatabase`
`ACLKeysLevel1ChangeTicket`	Primer nivel permitido para Change (Possible, PossibleAdd, PossibleNot)	`Possible, PossibleAdd, PossibleNot`
`ACLKeysLevel2::PropertiesTicket`	Claves de Match permitidas (Queue, State, DynamicField, etc.)	`Queue, State, CustomerUser, ...`
`ACLKeysLevel2::PossibleTicket`	Claves de Change permitidas (Form, FormStd, Action, Process, Ticket)	`Form, FormStd, Action, ...`
`ACLKeysLevel3::Actions###DefaultTicket`	Lista de todas las acciones posibles en la UI (AgentTicketClose, AgentTicketEmail, …)	(ver lista)

Consejo: Ajuste ACLKeysLevel* para poblar la UI de ACL solo con entradas relevantes.

Evaluación, Stop-on-Match y rendimiento

La evaluación de las ACL (listas de control de acceso) determina qué reglas se aplican cuando se carga un ticket o se ejecuta una acción en el sistema. Una configuración eficiente de estos procesos, así como optimizaciones de rendimiento específicas, son cruciales para garantizar una interfaz de agente fluida y escalable.

Ciclo de evaluación

Cada vez que un agente abre un ticket o ejecuta una acción (p. ej., hacer clic en un botón), OTOBO recorre la lista de todas las ACL activas ordenadas por su clave de ordenación (nombre o ID). El siguiente flujo muestra el proceso de verificación y ejecución:

flowchart TB
    A[Carga de ticket / Acción de usuario] --> B{Lista de ACL activas}
    B --> C[Verificación ACL1: ¿Match?]
    C -->|sí| D[Ejecutar ConfigChange 1]
    C -->|no| E[Verificación ACL2]
    D --> F{¿StopAfterMatch=1?}
    F -->|sí| G[Parar: no más ACLs]
    F -->|no| E
    E -->|…| H[Verificación ACLN]
    H -->|sí| I[Ejecutar ConfigChange N]
    H -->|no| J[Comportamiento estándar]

Match (ConfigMatch): Aquí se verifican criterios como Queue, Status, Priority o DynamicFields.
Change (ConfigChange): Define qué elementos de la UI se eliminan o añaden (Possible, PossibleAdd, PossibleNot) o qué acciones automáticas se realizan (cambio de cola/estado).
StopAfterMatch: Si se establece en 1, el procesamiento se interrumpe después de la primera ACL que coincida.

Recuerde: Un StopAfterMatch configurado correctamente evita que las ACL posteriores provoquen cambios no deseados.

Estrategias de Stop-on-Match

Opción	Efecto
StopAfterMatch=1	Tan pronto como una ACL coincide, no se verifica ninguna otra; ideal para reglas exclusivas.
StopAfterMatch=0	Se verifican todas las ACL; necesario cuando varias ACL deben intervenir independientemente.

Consejo: Los prefijos numéricos (p. ej., 100-, 200-) en el nombre de la ACL controlan el orden natural y, por tanto, la prioridad de las reglas críticas.

Optimización de rendimiento

Un gran conjunto de ACL puede aumentar los tiempos de carga de los formularios de tickets. Estas medidas ayudan a aumentar el rendimiento:

Ajustar CacheTTL: En SysConfig bajo ACL::CacheTTL (p. ej., 3600 s) se define cuánto tiempo permanecen las definiciones de ACL cargadas en la caché.
Activar Preselection-Cache: El módulo TicketACL::ACLPreselection rellena las opciones preseleccionadas de antemano y ahorra verificaciones repetidas.
Reducción de reglas: Elimine ACL obsoletas o duplicadas y agrupe reglas similares.
Optimizar secuencia: Coloque las ACL que coinciden con frecuencia al principio de la lista.
Campos indexados: Utilice índices de DB para DynamicFields y otras propiedades consultadas con frecuencia.

<Setting ID="ACL::CacheTTL">
    <Group>Core::Ticket::ACL</Group>
    <Value>3600</Value>
    <Description>Tiempo de vida de la caché para backends de ACL de DB en segundos.</Description>
</Setting>

Mantenimiento y mejores prácticas

Práctica	Beneficio
Exportación YAML	Versione las ACL en Git para rastrear los cambios.
Documentación	Cree un registro de cambios con marcas de tiempo, autor y objetivo de la ACL.
Revisión de reglas	La revisión periódica en equipo evita solapamientos.
Entorno de prueba	Valide las nuevas ACL con tickets de prueba controlados.
Depuración de logs	Active los logs de depuración (`TicketACL::Debug::Enabled`) para obtener información detallada.

Configurar depuración

<Setting ID="TicketACL::Debug::Enabled">
    <Group>Core::Ticket::ACL</Group>
    <Value>1</Value>
    <Description>Activar depuración de ACL</Description>
</Setting>
<Setting ID="TicketACL::Debug::Filter###00-DefaultTicket.xml">
<Group>Core::Ticket::ACL</Group>
<Value>&lt;OTOBO_TICKET_TicketID&gt;</Value>
<Description>Filtro para salidas de depuración por ID de ticket.</Description>
</Setting>

Mediante estas estrategias específicas, se asegura de que su infraestructura de ACL en OTOBO siga siendo potente y mantenible, incluso en entornos grandes y distribuidos.

Ejemplos prácticos, gobernanza y referencia

En esta parte final del artículo, mostramos mediante escenarios concretos cómo se utilizan las ACL en OTOBO de forma práctica. A continuación, tratamos métodos de gobernanza probados y hacemos referencia a documentación adicional.

Ejemplos prácticos

1. Priorización automática en la cola “Alarma”

Objetivo: Mover tickets con prioridad 5 (muy alta) inmediatamente a la cola Alarma y notificar al responsable.

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

Configuración básica Datos básicos de ACL y configuración de Match

Configuración de acción Cambio de ACL: Cambio de cola y añadir botón

2. Protección de escalado para tickets de prioridad “muy alta”

Objetivo: Evitar que se cierren tickets con prioridad de base de datos 5.

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

Protección de escalado Cambio de ACL: Ocultar botón de cierre

3. Restricción de UI por cola

Objetivo: En la cola Soporte, la opción de estado resuelto no debe estar disponible.

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

Eliminar estado Cambio de ACL: Eliminar opción de estado

4. Restricción de proceso de cliente

Objetivo: Los clientes no pueden mover sus propios tickets a otras colas.

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

Restringir proceso de cliente Cambio de ACL: Ocultar botón de mover para clientes

5. Escalado basado en tiempo después de 48 horas

Objetivo: Los tickets que llevan más de 48 horas abiertos se asignan automáticamente a Agentes Senior.

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

Nota: Este escenario puede requerir una extensión para criterios de coincidencia basados en tiempo.

Gobernanza y documentación

Medida	Descripción
Convención de nombres	Prefijos numéricos (p. ej., `100-`, `200-`) para orden y claridad.
Registro de cambios	Registre `Name`, `Comment`, `ChangeTime` y `ChangeBy` para cada cambio de ACL.
Proceso de revisión	Realice revisiones periódicas para evitar solapamientos y conflictos.
Versionado	Exporte las ACL como YAML y versione en Git o una herramienta de documentación.
Pruebas	Valide las ACL en un entorno de prueba con tickets de prueba específicos.

Referencias adicionales

Referencia de ACL (YAML): Kernel/Config/Files/ZZZACL.pm (generado)
Claves de ACL de SysConfig: Términos de nivel 1–3 para control fino (Core::Ticket::ACL)
Documentación de DynamicField: Conexión de campos dinámicos en ACL

Con estos ejemplos prácticos y recomendaciones de gobernanza, ahora dispone de las herramientas necesarias para operar ACL en OTOBO de forma segura, eficiente y trazable.