KARATE CLUB

Como Administrador del sistema
Quiero definir roles con permisos diferenciados
Para que cada usuario solo acceda a las funcionalidades que le corresponden

1. Descripción Funcional

El sistema debe implementar control de acceso basado en roles (RBAC). Tres roles principales: Admin (acceso total), Monitor (asistencia y eventos de su grupo), Familia (ver calendario e inscribirse a eventos).

1. Criterios de Aceptación (Gherkin)

```gherkin
Feature: Roles y permisos
Como sistema
Quiero controlar acceso por roles
Para garantizar seguridad

Scenario: Admin puede gestionar alumnos
    Dado que inicio sesión como Admin
    Cuando accedo al módulo de alumnos
    Entonces debo ver opciones: Crear, Editar, Eliminar

Scenario: Monitor solo puede pasar lista de su grupo
    Dado que inicio sesión como Monitor del grupo "Infantil" 
    Cuando accedo a "Pasar lista" 
    Entonces solo debo ver alumnos del grupo "Infantil" 
    Y no debo poder editar datos de alumnos

Scenario: Familia solo ve calendario e inscripciones
    Dado que inicio sesión como Familia
    Cuando accedo a la aplicación
    Entonces debo ver: Calendario, Mis inscripciones, Ficha de mi hijo
    Y NO debo ver: Gestión de alumnos, Cuotas, Licencias
```

1. Definición de Roles

1. Admin (Administrador)
   Permisos: TODO
   - CRUD completo de alumnos, licencias, cuotas, eventos, resultados
   - Gestión de usuarios y roles
   - Configuración del sistema
   - Exportaciones
   - Comunicación

1. Monitor (Instructor)
   Permisos limitados:
   - ✅ Pasar lista (solo su grupo/centro)
   - ✅ Ver calendario completo
   - ✅ Crear/editar eventos
   - ✅ Registrar resultados de competiciones
   - ✅ Ver ficha de alumnos (solo lectura)
   - ❌ NO puede: Editar alumnos, gestionar cuotas, gestionar licencias, ver datos financieros

1. Familia/Alumno
   Permisos mínimos:
   - ✅ Ver calendario de eventos
   - ✅ Inscribirse/cancelar inscripción a eventos
   - ✅ Ver ficha de su(s) hijo(s): datos personales, asistencia, licencia, cuotas, competiciones
   - ❌ NO puede: Ver otros alumnos, gestionar nada, acceder a módulos administrativos

1. Implementación Técnica

Supabase Auth + Row Level Security (RLS):
- Tabla `users` con campo `role` (enum: admin, monitor, familia)
- Políticas RLS en todas las tablas principales
- Middleware de Next.js para proteger rutas
- Componentes condicionales según rol

1. Definition of Done (DoD)

- [ ] Modelo User con campo role en Supabase
- [ ] Políticas RLS configuradas en todas las tablas
- [ ] Middleware de Next.js para protección de rutas
- [ ] HOC o hook personalizado para verificar permisos
- [ ] Interfaz de asignación de roles (solo Admin)
- [ ] Menú de navegación dinámico según rol
- [ ] Pantalla de "Acceso denegado" para intentos no autorizados
- [ ] Tests de permisos por rol
- [ ] Documentación de permisos

1. Estimación

Story Points: 8 | Horas: 13-21h

1. Referencias

Relacionado con: RF-009, RNF-003