Esta guía explica cómo Axentra controla qué puede hacer cada usuario dentro del sistema, cómo crear roles personalizados para su empresa, y por qué los roles del sistema están bloqueados.
Un rol es una colección de permisos. Cada permiso autoriza una acción específica dentro de un módulo (por ejemplo, pos.transaction.void permite anular transacciones de POS).
En lugar de asignar 50 permisos individuales a cada usuario, usted asigna roles y los permisos vienen incluidos.
Un usuario es una cuenta con la que alguien inicia sesión en Axentra. Un usuario puede tener uno o más roles asignados.
Si un usuario tiene varios roles, sus permisos efectivos son la unión de los permisos de todos sus roles. Si cualquiera de sus roles concede un permiso, el usuario lo tiene — aunque otro rol no lo conceda.
Ejemplo: Un usuario con
CASHIERyWAITER:
CASHIERpermite operar el POSWAITERpermite abrir órdenes de restaurante- El usuario puede hacer ambas cosas
Axentra viene con 12 roles seleccionados para cubrir las funciones más comunes en un ERP. Estos roles están bloqueados: no se pueden editar, eliminar, ni renombrar. Cada vez que reinicia el servidor, Axentra reinstala los permisos originales de cada rol del sistema desde el código fuente.
| Rol | Para quién | Resumen |
|---|---|---|
| SUPER_ADMIN | Dueño de la plataforma | Acceso total, comodín. Operaciones de emergencia |
| ADMIN | Administrador del tenant | Configuración, usuarios, certificados, periodos, integraciones |
| MANAGER | Jefe de departamento o turno | Publica diario, aprueba descuentos, gestiona precios, supervisa |
| ACCOUNTANT | Contador | Borrador de asientos, CxC, CxP, FX, impuestos, reportes fiscales |
| CASHIER | Cajero de POS | Abrir/cerrar su sesión, ventas, descuentos rutinarios |
| SUPERVISOR | Supervisor de turno POS | Cajero + anulaciones, overrides, devoluciones, 86 items |
| WAITER | Mesero | Abrir/cerrar órdenes, enviar a cocina, transferir mesas |
| WAREHOUSE | Almacén | Movimientos, transferencias, conteos físicos |
| SALESPERSON | Vendedor CRM | Su propio pipeline, cotizaciones, actividades |
| HR_ADMIN | RRHH y Nómina | Empleados, corridas de nómina, TSS |
| DEALER | Concesionario | Vehículos, deals, trade-ins |
| AUDITOR | Auditoría | Solo lectura en todos los módulos + logs de auditoría |
Los roles del sistema están definidos en código y forman parte del contrato de seguridad de Axentra. Al estar bloqueados:
MANAGER o CASHIER al diagnosticar un problema.ADMIN el permiso de gestionar usuarios y quedar fuera de su propia empresa.Si necesita un comportamiento distinto, cree un rol personalizado (ver más abajo).
Vaya a Configuración → Roles y Permisos para gestionar los roles personalizados de su empresa.
MAYÚSCULAS_CON_GUIONES_BAJOS. La caja de texto automáticamente:
mesero senior! produce MESEROSENIOR; escribir mesero_senior produce MESERO_SENIORpos.transaction.void) en grisN / M seleccionadosSi el rol que necesita es muy parecido a uno del sistema, duplíquelo en lugar de crear desde cero:
Caso típico: "Quiero un Manager pero sin permisos de nómina". → Duplique
MANAGERcomoMANAGER_OPS, abra el módulo Nómina y haga clic en Limpiar, guarde.
Solo se puede editar el descripción y el conjunto de permisos. El nombre es inmutable después de creado para mantener la trazabilidad de las asignaciones a usuarios (los logs de auditoría guardan el nombre del rol al momento de asignarlo).
Si necesita renombrar un rol personalizado:
Un rol solo se puede eliminar si:
Para eliminar un rol con usuarios asignados:
A-Z, dígitos 0-9 y guión bajo _.ADMIN o MANAGER).Recuerde: los permisos del usuario son la unión de todos los roles asignados. Si tiene 3 roles, sus permisos efectivos incluyen todo lo que cualquiera de los 3 conceda.
Los permisos siguen el patrón:
<módulo>.<objeto>.<acción>[.<calificador>]
Todo en minúsculas, separado por puntos. Ejemplos:
| Permiso | Significado |
|---|---|
pos.transaction.void |
Anular una transacción de POS |
gl.entry.post |
Publicar (no solo borrar) un asiento contable |
ecf.doc.sign |
Firmar un comprobante e-CF |
received_ecf.approve |
Aprobar comercialmente un e-CF recibido |
pos.session.close:any |
Cerrar la sesión de POS de cualquier cajero |
pos.session.close:own |
Cerrar solo la propia sesión |
config.update |
Editar la configuración de la empresa (incluye los datos de la tienda pública) |
storefront.publish |
Activar o desactivar el switch principal de la tienda pública — separado de config.update para que un rol de marketing pueda publicar/despublicar sin acceso a la configuración general |
inventory.product.manage |
Crear, editar y marcar productos como públicos/privados |
* |
Comodín — solo SUPER_ADMIN lo tiene |
Hay alrededor de 125 permisos en el sistema, agrupados en 20+ módulos. La pantalla de creación de roles muestra el catálogo completo con descripciones por módulo.
Los permisos no son solo decorativos — se verifican en cuatro capas:
@requires(perm: "..."). Aunque alguien intente llamar la API directamente, el servidor rechaza la petición.audit_logs con el usuario, la acción intentada y la marca de tiempo. Las acciones sensibles concedidas (publicar asiento, firmar e-CF, eliminar rol, etc.) también se registran.Para la mayoría de las empresas pequeñas y medianas, los 12 roles del sistema cubren bien las funciones típicas. Empezar simple es la mejor estrategia.
Si necesita "casi MANAGER pero sin acceso a payroll", duplique. No fragmente más de lo necesario — cada rol nuevo es un mantenimiento adicional cuando lleguen actualizaciones del software.
Use nombres que describan el cargo o la función, no la persona:
MESERO_SENIOR, ASISTENTE_CAJA, ENCARGADO_INVENTARIOJUAN, MI_ROL, EL_BUENOAsigne a cada usuario los roles mínimos que necesita para hacer su trabajo. Es más fácil agregar permisos cuando hagan falta que rastrear quién tuvo acceso a algo cuando un dato sensible se filtró.
SUPER_ADMIN tiene el comodín * — concede absolutamente todos los permisos, incluyendo borrar la base de datos y reiniciar el servidor. Asigne este rol solo al dueño técnico de la plataforma y a una cuenta de respaldo. Para administración día a día, use ADMIN.
Cada trimestre, revise:
ADMIN? ¿Siguen necesitándolo?No directamente. Duplique el rol con el nuevo nombre, reasigne los usuarios y elimine el rol viejo.
Los roles del sistema están bloqueados a tres niveles: la interfaz no muestra el botón Eliminar, el servidor rechaza la mutación con SYSTEM_ROLE_LOCKED, y aunque alguien manipule la base de datos, al reiniciar el servidor se reinstalarían. Esto protege la integridad de la plataforma.
Los permisos se calculan en cada petición al servidor, no se cachean. El usuario verá los nuevos permisos en su siguiente acción (en cuestión de segundos). No es necesario que cierre sesión.
*?No. El comodín * está reservado para SUPER_ADMIN. Si necesita un rol con casi todos los permisos, duplique ADMIN y modifíquelo.
No hay un límite duro, pero piense bien antes de pasar de 5–10 roles personalizados — la complejidad para sus administradores crece exponencialmente con el número de roles.
Por defecto, solo ADMIN y SUPER_ADMIN tienen los permisos rbac.role_group.{create,update,delete}. Si quisiera otorgárselos a otro rol, primero tendría que duplicar uno y agregarle esos permisos — pero pregúntese si realmente conviene; gestionar roles es una operación crítica de seguridad.
Ver también: