Roles y módulos
TankOS implementa cinco roles de dominio con separación de funciones (SoD) forzada a nivel de servidor. Los roles determinan qué módulos son accesibles y qué acciones están permitidas para cada perfil de usuario. La frontera de seguridad vive en el API — la visibilidad de la interfaz es un reflejo del rol, no el control de acceso real.
Los cinco roles
| Rol | Nombre técnico | En una línea |
|---|---|---|
| Operador | tankos_operator | Operador de planta y aforador. Captura aforos y lecturas manuales, opera lotes de custodia y gestiona alarmas operativas. No aprueba ni emite tickets. |
| Técnico de laboratorio | tankos_lab_technician | Crea y envía muestras de laboratorio y lecturas manuales. Tiene lectura de custodia para contexto operativo. No aprueba. |
| Supervisor | tankos_supervisor | Aprueba y anula muestras de laboratorio y aforos; emite y anula tickets de custodia; publica cambios de ingeniería (strapping). El superset operativo. No edita configuración de ingeniería. |
| Ingeniero | tankos_engineer | Configura tanques, dispositivos, geometría y tablas de strapping. Opera y afora custodia. No aprueba muestras de lab ni genera reportes. |
| Administrador | tankos_admin | Gestiona usuarios, API keys, catálogos, auditoría y reportes. Sin authorities operativas (no lab/custodia/ingeniería) — mínimo privilegio deliberado. |
Acceso por módulo
La tabla indica el nivel de acceso que cada rol tiene sobre cada módulo funcional del sistema.
| Módulo | Operador | Técnico Lab | Supervisor | Ingeniero | Admin |
|---|---|---|---|---|---|
| Operación SCADA (dashboard + alarmas) | Lectura y escritura | Sólo lectura | Lectura y escritura | Sólo lectura | Sólo lectura |
| Laboratorio (muestras + adjuntos) | No accede | Envío y edición | Aprobación y anulación | No accede | No accede |
| Custodia (lotes + aforos + tickets) | Planifica, opera y afora | Sólo lectura | Planifica, afora, emite y anula tickets | Planifica, opera y afora | No accede |
| Ingeniería (tanques + dispositivos + strapping) | No accede | No accede | Publicación | Configuración y publicación | No accede |
| Reportes (4 tipos PDF) | Generación y lectura | No accede | Generación y lectura | No accede | Lectura |
| Auditoría (log inmutable + visor) | No accede | No accede | No accede | No accede | Acceso completo |
| Catálogos (productos + plantillas) | No accede | No accede | No accede | No accede | Configuración |
| Administración (usuarios + API keys + sistema) | No accede | No accede | No accede | No accede | Acceso completo |
| Motor MPMS* | — | — | — | — | — |
*El motor de cálculo MPMS opera automáticamente en cada ciclo de telemetría; no es una pantalla accesible por rol. Los resultados (TOV/GOV/GSV/NSV/Masa + factores) se consultan en el detalle de tanque y en los tickets de custodia.
Separación de funciones (SoD)
Las siguientes reglas de control interno están implementadas en el servidor y se aplican independientemente de la interfaz utilizada:
- El que envía una muestra de laboratorio no puede aprobarla — submitter ≠ approver.
- El que invalida una muestra no puede ser el aprobador original — invalidator ≠ approvedBy.
- El que afora un lote de custodia no puede emitir el ticket — gauger ≠ ticketer.
- El administrador no tiene authorities operativas (lab/custodia/ingeniería) — principio de mínimo privilegio deliberado (no es un olvido de configuración).
Intentar saltarlas — por ejemplo, llamando directamente al API — devuelve 403 Forbidden.
La visibilidad de botones en la UI es orientativa; la autorización real ocurre en el guard
del API (@Authorities / @AnyAuthority).
Para empezar según tu rol
Una vez identificado tu rol, consulta la guía de uso por rol para instrucciones detalladas de cada perfil, y el manual de usuario para los flujos operativos paso a paso.