4.4 KiB
4.4 KiB
RF-MGN-001-002: Gestión de Roles y Permisos (RBAC)
Módulo: MGN-001 - Fundamentos Prioridad: P0 (MVP) Story Points: 13 Estado: Definido Fecha: 2025-11-23
Descripción
El sistema debe permitir la gestión de roles y permisos granulares basados en RBAC (Role-Based Access Control). Los roles agrupan permisos CRUD sobre modelos y los usuarios heredan permisos según sus roles asignados.
Actores
- Actor Principal: Administrador de Sistema
- Actores Secundarios: Usuario final (consume permisos)
Precondiciones
- Usuario administrador debe estar autenticado
- Sistema debe tener modelos registrados en auth.models
- Base de datos debe estar disponible
Flujo Principal
- Administrador accede a módulo de Gestión de Roles
- Administrador crea nuevo rol con nombre y descripción
- Administrador selecciona modelo (ej: sale.order)
- Administrador asigna permisos CRUD: create, read, update, delete
- Sistema crea registros en auth.permissions (rol + modelo + permisos)
- Administrador asigna rol a usuarios (tabla auth.user_roles)
- Sistema valida que permisos se apliquen inmediatamente
- Usuario con rol asignado puede ejecutar acciones permitidas
Flujos Alternativos
FA-1: Rol con Herencia
- Si administrador define parent_role_id
- Sistema copia permisos del rol padre automáticamente
- Administrador puede agregar permisos adicionales
- Usuario hereda permisos del rol padre + permisos específicos
FA-2: Eliminación de Rol en Uso
- Si administrador intenta eliminar rol asignado a usuarios
- Sistema retorna error 400: "Rol en uso. Reasigne usuarios antes de eliminar"
FA-3: Usuario sin Permisos
- Usuario intenta acción sin permiso correspondiente
- Sistema valida permisos en middleware
- Sistema retorna error 403: "No tiene permisos para esta acción"
- Sistema registra intento en audit_log
FA-4: Conflicto de Permisos (Múltiples Roles)
- Usuario tiene múltiples roles con permisos contradictorios
- Sistema aplica política "allow overrides deny" (si algún rol permite, se permite)
Reglas de Negocio
- RN-1: Un usuario puede tener múltiples roles
- RN-2: Un rol puede tener múltiples permisos sobre múltiples modelos
- RN-3: Permisos son granulares: create, read, update, delete por modelo
- RN-4: Herencia de roles: hijo hereda todos los permisos del padre
- RN-5: Roles predefinidos: Administrator (todos los permisos), User (solo lectura)
- RN-6: Administrador tiene permisos absolutos (bypass RBAC)
- RN-7: Política de resolución: "allow overrides deny"
Criterios de Aceptación
- Administrador puede crear, editar y eliminar roles
- Administrador puede asignar permisos CRUD por modelo a roles
- Administrador puede asignar múltiples roles a un usuario
- Usuario solo puede ejecutar acciones para las que tiene permisos
- Sistema retorna 403 cuando usuario sin permisos intenta acción
- Herencia de roles funciona correctamente (hijo hereda permisos del padre)
- Roles predefinidos (Administrator, User) existen por defecto
- Cambios de permisos se aplican inmediatamente sin logout
- Sistema registra intentos de acceso no autorizado en audit_log
Entidades Involucradas
- Principales:
- auth.roles (name, description, parent_role_id, is_admin)
- auth.permissions (role_id, model_id, can_create, can_read, can_update, can_delete)
- auth.user_roles (user_id, role_id)
- Relacionadas:
- auth.models (nombre de modelos del sistema)
- auth.users (usuarios con roles)
Referencias
Notas Técnicas
- Patrón Odoo: Similar a res.groups + ir.model.access (pero más simple)
- Patrón Gamilit: RBAC con tabla permissions + middleware de validación
- Middleware: Guard/Interceptor que valida permisos antes de ejecutar acción
- Caché: Cachear permisos de usuario en Redis para performance
- Backend: NestJS Guards + CASL para RBAC
- Frontend: Hook usePermissions(['sale.order.create']) para condicionar UI
Dependencias
- RF Dependientes: RF-MGN-001-001 (Autenticación)
- Bloqueante para: Todos los módulos transaccionales (necesitan validar permisos)