ACLs de OTOBO Znuny

Las Listas de Control de Acceso (ACLs) en OTOBO son la base de una gestión de permisos robusta. En este subtema aprenderá:

Conceptos y Valor de Negocio: Por qué las ACL son indispensables.
Visión General de la 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 Valor de Negocio

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 (por ejemplo, cerrar tickets) contra el uso no autorizado.
Usabilidad: Oculte dinámicamente botones o menús irrelevantes para no sobrecargar al usuario.
Automatización: Controle flujos de tickets (priorización, escalada, asignación) directamente a través de reglas de ACL, sin código adicional.
Mantenibilidad: Exporte, importe y versione ACLs de forma centralizada, ideal para entornos multi-instancia.

1.1 ACLs basadas en Roles y Criterios

Basadas en Roles: Asignación basada en roles o grupos de agentes (por ejemplo, Admin vs. Agente de Soporte).
Basadas en Criterios: Control mediante atributos de ticket (Cola, Estado, Prioridad, CamposDinámicos, IDCliente).

La combinación de ambos enfoques permite reglas precisas, por ejemplo: "Solo los agentes senior mueven tickets con prioridad > 3 a la cola de desarrollo."

2. Visión General de la Arquitectura

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

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

perl

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

Nota: El superusuario (UserID 1) ignora automáticamente todas las ACL, para no bloquearse a sí mismo.

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

Sección	Tarea
Match	Define condiciones: Comprueba atributos de ticket (Properties) o valores de DB (PropertiesDatabase).
Action	Especifica qué elementos de la UI (botones, campos) se muestran u 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, por ejemplo, permitir solo colas o estados específicos.
PossibleAdd: Añadir valores adicionales en una selección limitada.
PossibleNot: Eliminar botones específicos (por ejemplo, AgentTicketClose) de la UI.

4. Ajustes Importantes de SysConfig

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

Clave	Descripción	Valor de Ejemplo
`ACL::CacheTTL`	Duración 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 de tickets. 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 realiza una acción (por ejemplo, hacer clic en un botón), OTOBO recorre la lista de todas las ACL activas ordenadas según su clave de ordenación (nombre o ID). El siguiente proceso muestra el flujo de verificación y ejecución:

Match (ConfigMatch): Aquí se verifican criterios como Cola, Estado, Prioridad o Campos Dinámicos.
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 detiene después de la primera ACL coincidente.

Recordatorio: Un StopAfterMatch correctamente establecido evita que las ACL posteriores desencadenen cambios no deseados.

Estrategias de Stop-on-Match

Opción	Efecto
StopAfterMatch=1	Tan pronto como una ACL coincide, no se verifica ninguna más; ideal para reglas exclusivas.
StopAfterMatch=0	Se verifican todas las ACL; necesario si varias ACL deben intervenir de forma independiente.

Consejo: Los prefijos numéricos (por ejemplo, 100-, 200-) en el nombre de la ACL controlan la ordenación natural y, por lo tanto, la prioridad de las reglas críticas.

Optimización del Rendimiento

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

Ajustar CacheTTL: En SysConfig, bajo ACL::CacheTTL (por ejemplo, 3600 s), se define cuánto tiempo permanecen en caché las definiciones de ACL cargadas.
Activar caché de preselección: El módulo TicketACL::ACLPreselection rellena opciones preseleccionadas de antemano y ahorra verificaciones repetidas.
Reducción de reglas: Elimine ACLs 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 Campos Dinámicos y otras propiedades consultadas con frecuencia.

xml


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

Mantenimiento y Mejores Prácticas

Práctica	Beneficio
Exportación YAML	Versionar ACLs en Git para rastrear cambios.
Documentación	Crear un registro de cambios con marcas de tiempo, autor y propósito de la ACL.
Revisión de reglas	La revisión periódica en equipo evita solapamientos.
Entorno de pruebas	Validar nuevas ACLs con tickets de prueba controlados.
Depuración de logs	Activar logs de depuración (`TicketACL::Debug::Enabled`) para obtener información detallada.

Configurar Depuración

xml


<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 tanto de alto rendimiento como mantenible, incluso en entornos grandes y distribuidos.

Ejemplos Prácticos, Gobernanza y Referencia

En esta sección final del artículo, mostramos cómo se utilizan las ACL en OTOBO de forma práctica con escenarios concretos. A continuación, abordamos métodos de gobernanza probados y proporcionamos referencias para una mayor profundización.

Ejemplos Prácticos

1. Priorización Automática en la Cola "Alarma"

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

yaml

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

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

Configuración de Acción Cambio de ACL: Cambio de cola y adición de botón

2. Protección contra Escalada para Tickets con Prioridad "Muy Alta"

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

yaml

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

Protección contra Escalada 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.

yaml

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

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

4. Restricción de Procesos de Cliente

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

yaml

- 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. Escalada basada en Tiempo después de 48 Horas

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

yaml

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

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 (por ejemplo, `100-`, `200-`) para ordenación y claridad.
Registro de Cambios	Registrar `Name`, `Comment`, `ChangeTime` y `ChangeBy` para cada cambio de ACL.
Proceso de Revisión	Realizar revisiones periódicas para evitar solapamientos y conflictos.
Versionado	Exportar ACLs como YAML y versionarlas en Git o una herramienta de documentación.
Pruebas	Validar ACLs en un entorno de pruebas con tickets de prueba específicos.

Referencias Adicionales

Referencia de ACL (YAML): Kernel/Config/Files/ZZZACL.pm (generado)
Claves de SysConfig para ACL: Términos de Nivel 1-3 para control fino (Core::Ticket::ACL)
Documentación de Campos Dinámicos: Integración de campos dinámicos en ACLs

Con estos ejemplos prácticos y recomendaciones de gobernanza, ahora tiene las herramientas para operar las ACL en OTOBO de manera segura, eficiente y rastreable.

ACLs de OTOBO Znuny ​

1. Conceptos y Valor de Negocio ​

1.1 ACLs basadas en Roles y Criterios ​

2. Visión General de la Arquitectura ​

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

4. Ajustes Importantes de SysConfig ​

Evaluación, Stop-on-Match y Rendimiento ​

Ciclo de Evaluación ​

Estrategias de Stop-on-Match ​

Optimización del Rendimiento ​

Mantenimiento y Mejores Prácticas ​

Configurar Depuración ​

Ejemplos Prácticos, Gobernanza y Referencia ​

Ejemplos Prácticos ​

1. Priorización Automática en la Cola "Alarma" ​

2. Protección contra Escalada para Tickets con Prioridad "Muy Alta" ​

3. Restricción de UI por Cola ​

4. Restricción de Procesos de Cliente ​

5. Escalada basada en Tiempo después de 48 Horas ​

Gobernanza y Documentación ​

Referencias Adicionales ​

ACLs de OTOBO Znuny

1. Conceptos y Valor de Negocio

1.1 ACLs basadas en Roles y Criterios

2. Visión General de la Arquitectura

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

4. Ajustes Importantes de SysConfig

Evaluación, Stop-on-Match y Rendimiento

Ciclo de Evaluación

Estrategias de Stop-on-Match

Optimización del Rendimiento

Mantenimiento y Mejores Prácticas

Configurar Depuración

Ejemplos Prácticos, Gobernanza y Referencia

Ejemplos Prácticos

1. Priorización Automática en la Cola "Alarma"

2. Protección contra Escalada para Tickets con Prioridad "Muy Alta"

3. Restricción de UI por Cola

4. Restricción de Procesos de Cliente

5. Escalada basada en Tiempo después de 48 Horas

Gobernanza y Documentación

Referencias Adicionales