Roles y Permisos

Cada usuario tiene un rol que define sus capacidades en el sistema.

Jerarquia de Roles

Diagrama

JERARQUIA DE ROLES

• ADMIN - Nivel mas alto
  • USER - Empresas/clientes
    • SUBUSER - Empleados
    • POSTULANT - Nivel base

Relaciones

ADMIN

• Puede ver TODO
• Puede editar TODO
• Sin restricciones

USER

• Puede crear SUBUSERs
• Puede gestionar POSTULANTs (via UserProfile)
• Solo ve datos de su empresa

SUBUSER

• Hereda permisos del USER padre
• Puede ver datos de la empresa
• Permisos adicionales via ACL

POSTULANT

• Solo ve su propio perfil
• Aplica a vacantes publicas
• Sin acceso administrativo

Rol: Admin

Descripcion

El admin tiene acceso completo a la plataforma.

Funciones exclusivas:

• Dashboard de administracion (/app/admin)
• Metricas financieras (ingresos, MRR, churn)
• Gestion de suscripciones
• Ordenes y facturacion
• Configuracion global del sistema
• Acceso a todos los usuarios

Casos de Uso

Quien es admin:

• Equipo de soporte de la plataforma
• Desarrolladores
• Administradores del sistema

NO son admins:

• Clientes (empresas)
• Empleados de clientes
• Candidatos

Rol: User (Empresa)

Descripcion

El user representa una empresa o cliente de la plataforma.

Capacidades:

• Crear y gestionar proyectos
• Publicar vacantes
• Crear procesos de reclutamiento
• Administrar candidatos (postulantes)
• Crear subusers (empleados)
• Programar eventos/entrevistas
• Asignar pruebas
• Ver analytics de su empresa
• Configurar automatizaciones

Multi-Tenancy

Cada USER tiene su propio "tenant":

USER: Empresa A

• Sus propios proyectos
• Sus propias vacantes
• Sus propios candidatos (via UserProfile)
• Sus propios subusers
• Datos aislados de otras empresas

Nota: Los postulantes pueden pertenecer a multiples empresas (UserProfile).

Suscripcion

Los users tienen suscripciones:

• Plan basico, pro, enterprise
• Limites segun plan
• Facturacion mensual/anual
• Gestionado por admins

Rol: Subuser (Empleado)

Descripcion

El subuser es un empleado de la empresa (user).

Caracteristicas:

• Pertenece a un USER padre
• Hereda el contexto del padre
• Puede tener permisos ACL especificos
• Ve los mismos candidatos que el padre
• Puede tener funciones limitadas

Relacion con User

USER (Empresa A)

• SUBUSER: Reclutador 1
• SUBUSER: Reclutador 2
• SUBUSER: HR Manager
• SUBUSER: Hiring Manager

Todos ven los mismos candidatos y proyectos de Empresa A.

Effective User Pattern

El sistema usa "effective user" para subusers:

Cuando un subuser hace una query:

1. Se obtiene su parentId (user padre)
2. Se usa el parentId como ownerId
3. Ve los datos del user padre
4. No ve datos propios (no tiene)

Ejemplo: SUBUSER Maria (parentId: 123) - Al buscar candidatos, ve los de USER 123

Permisos ACL

Los subusers pueden tener permisos especificos:

Ejemplo:

• process.read ✓
• process.manage ✗ (solo lectura)
• events.read ✓
• events.manage ✓ (puede crear eventos)
• users.manage ✗ (no puede crear usuarios)

Esto permite roles como:

• Solo lectura
• Reclutador (eventos + candidatos)
• Manager (todo menos facturacion)
• Personalizado

Rol: Postulant (Candidato)

Descripcion

El postulant es un candidato que aplica a vacantes.

Capacidades:

• Crear y completar su perfil
• Aplicar a vacantes publicas
• Tomar pruebas asignadas
• Ver estado de aplicaciones
• Chatear con reclutadores
• Recibir notificaciones

Multi-Empresa

Un postulante puede pertenecer a multiples empresas:

POSTULANT: Juan Perez

• UserProfile con Empresa A
  • Notas: "Buen candidato"
  • Tags: ["senior", "frontend"]
  • Estado: activo
• UserProfile con Empresa B
  • Notas: "En proceso para PM"
  • Tags: ["pm", "experiencia"]
  • Estado: activo

Cada empresa tiene su propia vista del candidato. Datos personales compartidos, datos de relacion separados.

Portal del Candidato

El postulante accede a:

/my-resume

• Ver y editar perfil
• Subir documentos
• Experiencia y skills

/my-applications

• Ver aplicaciones
• Estado de cada una
• Historial

/my-tests

• Pruebas pendientes
• Tomar pruebas
• Ver resultados (si permitido)

Permisos por Rol

Matriz de Permisos

Leyenda:

• ✓ = Siempre tiene
• ○ = Configurable via ACL
• ✗ = Nunca tiene

Permisos de Datos

Que datos puede ver cada rol:

• ADMIN: Todo (sin restriccion de ownerId)
• USER: Datos donde ownerId = su id
• SUBUSER: Datos donde ownerId = parentId (user padre)
• POSTULANT: Solo su propio perfil y aplicaciones

Cambiar Rol

Solo Admin

Cambiar rol de usuario:

1. Solo admins pueden cambiar roles
2. Acceso: /app/users → Editar usuario
3. Seleccionar nuevo rol
4. Guardar cambios

Restricciones:

• No puedes cambiar tu propio rol
• No puedes crear admins (protegido)
• Cambio de user↔subuser requiere cuidado

Implicaciones

Cambiar USER → SUBUSER:

• Pierde sus propios datos
• Sus subusers quedan huerfanos
• Debe asignarse un parentId

Cambiar SUBUSER → USER:

• Se vuelve independiente
• Necesita crear sus propios datos
• Ya no ve datos del padre anterior

Cambiar POSTULANT → USER/SUBUSER:

• Generalmente no recomendado
• Perderia contexto de candidato
• Requiere setup completo

Mejores Practicas

Asignar Roles

DO:

• Dar el minimo rol necesario
• Usar subusers para empleados
• Configurar ACL para permisos especificos
• Revisar permisos periodicamente
• Documentar quien tiene que rol

DON'T:

• Dar rol admin a clientes
• Compartir cuentas
• Dar permisos excesivos "por si acaso"
• Olvidar revocar acceso a exempleados
• Crear usuarios sin rol claro

Seguridad

Recomendaciones:

• Contraseñas fuertes
• Verificacion de email
• Revisar accesos mensualmente
• Desactivar usuarios inactivos
• Log de cambios de rol

Proximos Pasos

• Crear Usuario - Proceso de alta
• Subusers - Gestion de empleados
• Permisos ACL - Sistema de permisos detallado