Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/DevCarlosRodriguez/Documentacion-Arccnova-2.0/llms.txt

Use this file to discover all available pages before exploring further.

ArccNova v2 actúa como proveedor de identidad de su propio ecosistema (ADR-003). La autenticación se basa en JWT HS256 y el control de acceso combina dos mecanismos que coexisten: la matriz de permisos por módulo (RBAC granular, ADR-015) y los 18 permisos protegidos por contraseña de acción para operaciones sensibles. Esta guía cubre ambos mecanismos desde el login hasta la auditoría de uso.
TenantId y BranchId se leen SIEMPRE del JWT, nunca del body de la petición. Enviarlos en el cuerpo de la solicitud no tiene ningún efecto: el backend los extrae exclusivamente del token de acceso (RT-01, ADR-007).

​
Estructura del JWT

El access token es un JWT HS256. La siguiente es la estructura de claims que lleva: 
{
  "sub": "3fa85f64-5717-4562-b3fc-2c963f66afa6",
  "name": "María García López",
  "email": "maria.garcia@constructoraacme.com",
  "tenant_id": "a1b2c3d4-0000-0000-0000-000000000001",
  "branch_id": "b2c3d4e5-0000-0000-0000-000000000002",
  "role": "Admin",
  "imp": false
}
ClaimDescripción
subPublicId (GUID) del usuario — identificador permanente para trazabilidad
nameNombre completo del usuario
emailCorreo electrónico del usuario
tenant_idIdentificador de la empresa activa en sesión
branch_idIdentificador del proyecto activo en sesión
roleRol del usuario en el proyecto activo
imptrue si la sesión es una impersonación de SysAdmin

​
Flujo de login

El login recibe correo y contraseña. Si las credenciales son correctas, el backend emite el access token JWT y un refresh token. Las validaciones de política de contraseña aplican solo al alta y al restablecimiento, no al login de cuentas existentes. Si la suscripción de la empresa está vencida o impaga en el momento del login, el comportamiento varía según el rol:
UsuarioComportamiento
CEOVe la pantalla de paywall con CTAs de pago hacia Stripe
No-CEOVe una pantalla genérica: “contacta al administrador del proyecto”
El sistema no notifica automáticamente al CEO cuando un usuario no-CEO intenta acceder con suscripción vencida (C07). El CEO solo se entera si el usuario lo contacta directamente.

​
Política de contraseñas (RN-01)

La política es única en todo el sistema y aplica en tres momentos: alta de cuenta en el registro, creación de usuarios por el CEO/Admin, y restablecimiento de contraseña.
RequisitoValor
Longitud mínima8 caracteres
Al menos una letra mayúscula✓
Al menos una letra minúscula✓
Al menos un carácter especial✓
La política de contraseñas aplica a creación y restablecimiento, no a la validación en el login de cuentas existentes que puedan haber sido creadas antes de que la política estuviera vigente.

​
Confirmación de correo y recuperación de contraseña

  • El enlace de confirmación de correo tiene vigencia de 72 horas y puede reenviarse cuantas veces sea necesario (C05 segunda ronda, RN-02).
  • El correo confirmado es obligatorio para iniciar sesión (RequireConfirmedEmail).
  • La recuperación de contraseña sigue el flujo estándar de token por correo. La nueva contraseña debe cumplir RN-01.

​
RBAC granular — extensión ADR-015

El control de acceso se basa en roles personalizados por empresa con una matriz de permisos submodule × acción. Esta es la extensión RBAC documentada en ADR-015.

​
Acciones disponibles por submodule

Cada submodule puede tener hasta 5 acciones habilitadas de forma independiente:
AcciónDescripción
VerLeer y listar registros
EscribirCrear nuevos registros
ActualizarEditar registros existentes
EliminarEliminar (soft-delete) registros
DescargarExportar o descargar documentos

​
Matriz de grupos y submodules

SubmoduleAcciones disponibles
RolesVer, Escribir, Actualizar, Eliminar, Descargar
UsuariosVer, Escribir, Actualizar, Eliminar, Descargar
PermisosVer, Escribir, Actualizar, Eliminar, Descargar
Permisos de usuarioVer, Escribir, Actualizar, Eliminar, Descargar
PromocionesVer, Escribir, Actualizar, Eliminar, Descargar

​
Permisos individuales y membresía por proyecto

Además del rol, un usuario puede recibir permisos individuales que se suman por encima de su rol en un proyecto específico (decisión 12, ADR-015). La membresía usuario-proyecto lleva:
  • El usuario
  • El proyecto (Branch)
  • El rol del usuario en ese proyecto
El mismo usuario puede tener el rol Admin en el proyecto A y solo lectura en el proyecto B (C12). Los permisos efectivos en el proyecto activo son: permisos del rol + permisos individuales adicionales.

​
El rol CEO — protegido

El rol CEO es el único rol protegido del sistema: no puede editarse ni eliminarse (C36, RN-05). Se crea automáticamente al dar de alta la empresa y se asigna al usuario que realizó el registro público. Todo lo demás (roles operativos como Admin, Asesor, etc.) son roles personalizados que el CEO o un Admin puede crear y modificar libremente.

​
Los 18 permisos protegidos (RN-07)

Existen exactamente 18 permisos protegidos, distribuidos en 5 áreas. Son una lista cerrada y exhaustiva (C33). Para ejecutar una de estas acciones, el sistema solicita al usuario su contraseña de acción (una contraseña dedicada, generada por el sistema y distinta de la contraseña de login).
  • EDITAR CONCEPTO DE MORA
  • ELIMINAR CONCEPTO POR MORA
  • VER COBROS
  • CARGAR COBROS
  • ACTUALIZAR COBROS
  • ELIMINAR COBROS
  • VER VENTAS
  • CARGAR VENTAS
  • ACTUALIZAR VENTAS
  • ELIMINAR VENTAS
  • VER CONTRATOS
  • CARGAR CONTRATOS
  • ACTUALIZAR CONTRATOS
  • ELIMINAR CONTRATOS
  • VER USUARIOS
  • CARGAR USUARIOS
  • ACTUALIZAR USUARIOS
  • ELIMINAR USUARIOS

​
Mecánica de los permisos protegidos (RT-10, C34)

1

El CEO/Admin otorga permisos protegidos a un usuario

Desde la pantalla de permisos, el CEO o Admin selecciona al usuario y marca cuáles de los 18 permisos protegidos tendrá habilitados.
2

El sistema genera una contraseña de acción

Al otorgar el primer permiso protegido, el sistema genera una única contraseña por usuario (permanente). Esta misma contraseña cubre todos los permisos protegidos que ese usuario tenga asignados, presentes y futuros.Ejemplo: si más adelante se le agrega ELIMINAR COBROS a un usuario que ya tenía EDITAR CONCEPTO DE MORA, ejercerá ambos con la misma contraseña de acción.
3

Contraseña de acción al ejecutar la operación

Cada vez que el usuario intenta ejecutar una acción protegida, el sistema presenta un diálogo solicitando su contraseña de acción. Si la contraseña es correcta, la operación procede.
4

La empresa puede desactivar un permiso protegido

El CEO/Admin puede desactivar cualquiera de los 18 permisos protegidos a nivel empresa. Una vez desactivado, esa acción deja de pedir contraseña para todos los usuarios de la empresa (C34). La desactivación es reversible.
Los permisos protegidos se configuran por empresa y se desactivan por empresa. El CEO y el Admin están exentos: ejecutan las acciones protegidas sin necesidad de ingresar contraseña de acción (C16, RT-11). La auditoría de uso de permisos se conserva permanentemente (C35, RT-08).
Punto abierto (flag 6): el arquitecto decidirá si v2 replica la contraseña estática generada del v1 o la sustituye por re-autenticación del propio usuario + permiso RBAC equivalente. La semántica de negocio (permisos por empresa, desactivables, CEO/Admin exentos) no cambia en ninguno de los dos casos.

​
Impersonación (SysAdmin)

El SysAdmin de la plataforma puede asumir la sesión de cualquier usuario de cualquier empresa para soporte y diagnóstico. El JWT generado para la sesión de impersonación lleva el claim imp: true. El campo sub sigue siendo el identificador del usuario impersonado para garantizar la trazabilidad en la auditoría.

Build docs developers (and LLMs) love

Get started for freeTalk to us