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.

El módulo Identity es el proveedor de identidad propio del ecosistema ArccNova (ADR-003). Autentica usuarios, emite y renueva sesiones, administra el catálogo de usuarios de cada empresa y resuelve el control de acceso de todo el sistema: roles personalizados, matriz de permisos por submódulo, permisos individuales, permisos protegidos por contraseña de acción y auditoría de uso permanente.

​
Alcance

  • Login con correo y contraseña
  • Refresh token
  • Registro público de empresa con Stripe Checkout
  • Recuperación y cambio de contraseña
  • Impersonación de usuario (SysAdmin)
  • Gestión de planes de precios (SysAdmin)
  • JWT HS256 con claims: sub, name, email, tenant_id, branch_id, role, imp

​
Modelo de dominio

​
Entidades ya implementadas

EntidadContenido
UsuarioNombre completo, correo (único), contraseña hasheada, rol, empresa, proyecto activo
SesiónAccess token JWT + refresh token

​
Extensión RBAC (por construir)

EntidadContenidoReferencia
RolPersonalizado por empresa; nombre y descripción; el rol CEO es protegido (no editable ni eliminable)Decisión 12; C36
Permiso (catálogo)Matriz submódulo × acción: Ver, Escribir, Actualizar, Eliminar, DescargarImagen C48
Rol-PermisoQué permisos otorga cada rolDecisión 12
Permiso individualPermisos por usuario por encima de su rolDecisión 12
Membresía usuario-proyectoA qué proyectos pertenece el usuario y con qué rol en cada unoC12
Permiso protegidoLos 18 permisos de acciones sensibles (lista cerrada, RN-07)C33
Contraseña de acciónGenerada por el sistema, por usuario, para ejercer sus permisos protegidosC34
Auditoría de usoRegistro permanente de cada uso de permisoC35

​
Matriz de permisos de referencia

GrupoSubmódulos incluidosAcciones disponibles
SeguridadRoles, Usuarios, Permisos, Permisos de usuario, PromocionesVer, Escribir, Actualizar, Eliminar, Descargar
G. ComercialContactos, Ventas, Créditos, Cotizaciones, Cobros, ReservasVer, Escribir, Actualizar, Eliminar, Descargar
LogísticaManzanas, LotesVer, Escribir, Actualizar, Eliminar, Descargar
TesoreríaConceptos, Gastos de proyecto, Gastos generales, Recibos, Panorama financieroVer, Escribir, Actualizar, Eliminar, Descargar
AjustesTipos de pago, Métodos de pago, Monedas, Días festivos, Proyectos, Sedes, Contratos, Tipos de recibosVer, Escribir, Actualizar, Eliminar, Descargar
ReportesReportes de ventas, financieros, de lotes, de contactosSolo Ver (ver implica descargar, C48)
Cada grupo dispone de un interruptor “Solo lectura” por módulo que desactiva todas las acciones de escritura de forma masiva.

​
Flujos

​
Flujo 4.1 — Login

1

Entrada de credenciales

El usuario ingresa su correo y contraseña.
2

Validación de credenciales

El servidor verifica credenciales. La política de contraseña (RN-01) aplica solo en alta y cambio, no al login de cuentas existentes.
3

Verificación del estado de suscripción

Si la suscripción de la empresa está vencida o impaga, el CEO ve el paywall con CTAs de pago. Un usuario que no es CEO ve el mismo paywall; si intenta pagar, el backend responde 403 billing-owner-required y se le redirige a una pantalla de “sin acceso” con el mensaje genérico “contacta al administrador del proyecto”. El sistema no notifica al CEO (C07).
4

Emisión de tokens

El servidor emite el access token JWT y el refresh token junto con los datos de sesión.

​
Estructura del JWT

{
  "sub": "usr_01J...",
  "name": "María González",
  "email": "maria@empresa.com",
  "tenant_id": "ten_01J...",
  "branch_id": "bra_01J...",
  "role": "Admin",
  "imp": false
}
Los claims tenant_id y branch_id son inyectados por el servidor a partir de la sesión activa. Nunca deben enviarse en el cuerpo de la solicitud; el backend los ignora si se incluyen y usa exclusivamente los del JWT.

​
Flujo 4.2 — Registro de empresa

1

Captura de datos del CEO

El CEO completa el formulario de registro con sus datos personales y los de la empresa.
2

Creación de cuenta

El sistema crea el usuario, la empresa y el rol CEO en todos los casos, aunque nunca se realice el pago (C04). La cuenta persiste indefinidamente; el acceso lo gobierna el estado de la suscripción.
3

Confirmación de correo electrónico

Se envía un enlace de confirmación con vigencia de 72 horas. Existe reenvío del correo (C05 segunda ronda). El correo es obligatorio para iniciar sesión (RequireConfirmedEmail).
4

Stripe Checkout

El CEO continúa a Stripe Checkout para seleccionar su plan y completar el primer pago. Ver módulo BillingSaas para el ciclo completo de suscripción.

​
Flujo 4.3 — Recuperación y cambio de contraseña

Flujo estándar de token por correo. La nueva contraseña debe cumplir la política RN-01 (mínimo 8 caracteres con al menos una mayúscula, una minúscula y un carácter especial).

​
Flujo 4.4 — Asignar rol y permisos (por construir)

1

Crear roles

El CEO (o un Admin con permiso delegado) crea roles y define sus permisos marcando las celdas de la matriz submódulo × acción.
2

Asignar usuarios a proyectos

Cada asignación lleva el rol del usuario en ese proyecto específico. El mismo usuario puede ser Admin en el proyecto A y solo lectura en el proyecto B (C12).
3

Permisos individuales

Por encima del rol, se pueden agregar permisos sueltos a un usuario concreto (Decisión 12).

​
Flujo 4.5 — Otorgar permisos protegidos (por construir)

1

Seleccionar permisos protegidos

El CEO o Admin selecciona al usuario y marca cuáles de los 18 permisos protegidos tendrá asignados.
2

Generación de contraseña de acción

El sistema genera la contraseña de acción del usuario: una sola por usuario, permanente, que cubre todos sus permisos protegidos. Ejemplo: a un usuario con permisos “eliminar concepto por mora” y “editar concepto de mora” se le agrega después “eliminar cobros” y ejerce los tres con la misma contraseña (C34).
3

Desactivación opcional por empresa

La empresa puede desactivar un permiso protegido; esa acción deja de pedir contraseña para todos los usuarios de esa empresa (C34).
4

Ejecución de la acción sensible

Al ejecutar una acción sensible (por ejemplo, eliminar un cobro), el sistema solicita la contraseña de acción. CEO y Admin están exentos de este paso (C16).

​
Flujo 4.6 — Impersonación (implementado)

El SysAdmin asume la sesión de cualquier usuario. El JWT emitido lleva el claim imp: true para identificar la sesión impersonada en los registros de auditoría.

​
Reglas de negocio

Mínimo 8 caracteres, con al menos una mayúscula, una minúscula y un carácter especial (Decisión 22). Aplica en alta de usuario, alta de empresa y restablecimiento de contraseña. No bloquea el login de cuentas existentes que no cumplan la política si su contraseña fue creada antes del cambio de regla.
El enlace de confirmación vence a las 72 horas y puede reenviarse (C05 segunda ronda). La cuenta no puede iniciar sesión hasta confirmar el correo.
La cuenta creada en el registro persiste indefinidamente aunque nunca se pague (C04). El acceso real lo gobierna el estado de la suscripción en BillingSaas.
Un usuario que no es CEO solo queda bloqueado, sin notificación automática al CEO (C07).
El rol CEO es el único rol del sistema que no puede editarse ni eliminarse (C36).
Un usuario puede tener roles o permisos distintos en proyectos distintos (C12). El alta de usuarios la realiza el CEO o un Admin/usuario con permiso delegado.
Los permisos que requieren contraseña de acción son una lista cerrada definida en C33:
#Permiso protegido
1EDITAR CONCEPTO DE MORA
2ELIMINAR CONCEPTO POR MORA
3CARGAR COBROS
4ACTUALIZAR VENTAS
5ACTUALIZAR CONTRATOS
6VER COBROS
7ELIMINAR USUARIOS
8ACTUALIZAR USUARIOS
9VER CONTRATOS
10CARGAR VENTAS
11CARGAR USUARIOS
12ELIMINAR CONTRATOS
13ELIMINAR VENTAS
14VER USUARIOS
15CARGAR CONTRATOS
16ACTUALIZAR COBROS
17ELIMINAR COBROS
18VER VENTAS
Una sola contraseña por usuario, generada por el sistema, permanente, que cubre todos sus permisos protegidos (C34). CEO y Admin están exentos (C16).
La empresa puede activar o desactivar globalmente cada permiso protegido para sus usuarios (C34).
Cada uso de permiso genera un registro permanente (sin purga) en la tabla de auditoría (C35).
Un solo permiso de “Ver módulo” por reporte; ver implica también descargar (C48).

​
Puntos abiertos

Los siguientes puntos están pendientes de decisión del arquitecto y no bloquean el desarrollo de otros módulos:
  1. Flag 1 (C05): Mecanismo del token de confirmación de correo — ¿se mantiene el token de Data Protection de ASP.NET Identity o se cambia a token propio? (Contrasta con ADR-003.)
  2. Flag 6 (C34): Contraseña de acción estática generada vs re-autenticación + permiso RBAC. La semántica de negocio (RN-07 a RN-09) no cambia independientemente de la decisión técnica.
  3. La nomenclatura final de los roles seed (CEO / Admin / Asesor de negocio vs SysAdmin / Admin / Agent / Auditor actualmente implementados) se resuelve al construir la matriz RBAC.

Build docs developers (and LLMs) love

Get started for freeTalk to us