# Sistema de notificaciones del Buscador Multisearch Quinta entrega del proyecto. Cierra la pieza que faltaba: cómo se notifica al usuario cada evento del proceso selectivo, por qué canal, con qué urgencia y bajo qué reglas configurables. Reemplaza y amplía el modelo de 3-4 fases que veníamos usando hasta ahora. El nuevo modelo trabaja con **10 fases formales** del proceso selectivo conforme al EBEP y al Reglamento General de Ingreso (RD 364/1995). --- ## 1. Las diez fases del proceso selectivo | # | Fase | Dónde se publica | Quién la necesita | |---|------|------------------|-------------------| | 1 | Oferta de Empleo Público (OEP) | BOE / boletín autonómico / provincial | Academia: planificación | | 2 | Convocatoria y bases | BOE Sec. II.B / autonómico / provincial | Academia + futuros opositores | | 3 | Presentación de solicitudes | (interno; plazo fijado en bases) | Opositor: inscripción | | 4 | Lista provisional admitidos/excluidos | BOE / sede electrónica | Opositor inscrito | | 5 | Lista definitiva admitidos/excluidos | BOE / sede electrónica | Opositor inscrito | | 6 | Fecha/hora/lugar del examen | Resolución de admitidos o posterior | Opositor admitido | | 7 | Desarrollo de ejercicios | Sede electrónica / tribunal | Opositor admitido | | 8 | Resultados y fase de méritos | Sede electrónica | Opositor admitido | | 9 | Relación de aprobados | BOE | Opositor aprobado + academia | | 10 | Documentación, nombramiento y toma de posesión | BOE / portal | Opositor aprobado | Además, hay **modificadores** que pueden aparecer cruzados con cualquier fase y que conviene tratar como eventos propios: - Corrección de errores (cualquier fase, especialmente bases) - Ampliación de plazo (fase 3 sobre todo) - Composición del tribunal (entre fase 5 y 6 típicamente) - Plantilla de respuestas (entre fase 7 y 8) - Aprobados sin plaza / constitución de bolsa (cerca de la fase 9) --- ## 2. Los cuatro canales de notificación ``` ┌──────────────────────────────────────────────────────────────┐ │ EVENTO DETECTADO │ │ ↓ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ MOTOR DE REGLAS │ │ │ │ Para cada usuario/equipo, evalúa qué canales aplican │ │ │ │ según: fase del evento, categoría, prioridad, │ │ │ │ proceso concreto, preferencias del usuario │ │ │ └──────────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌──────────────┬──────────────┬──────────────┬─────────────┐ │ │ │ Email diario │ Email/push │ Dashboard │ Calendario │ │ │ │ (push) │ inmediato │ (pull) │ iCal (pull) │ │ │ │ │ (push) │ │ │ │ │ └──────────────┴──────────────┴──────────────┴─────────────┘ │ └──────────────────────────────────────────────────────────────┘ ``` ### Canal 1: Email diario (resumen) Ya implementado en `02_email_template.html`. Recibe todo lo del día agrupado por bloques. Es el canal por defecto para todas las fases. ### Canal 2: Email inmediato (alerta) Nuevo. Llega a los minutos de detectarse el evento, sin esperar al resumen del día. Se reserva para eventos que requieren acción rápida o que el usuario ha marcado como críticos. Plantilla simplificada: una sola tarjeta con el evento, enlace al proceso completo y botón para silenciar futuras alertas de ese tipo. ### Canal 3: Dashboard web Nuevo. Pull, no push. El usuario entra cuando quiere y ve: - Estado de todos los procesos que sigue, con su timeline de 10 fases. - Calendario unificado de fechas clave. - Histórico de temarios con diffs. - Cola de propuestas del bucle de mejora continua para aprobar. - Métricas de la academia. ### Canal 4: Calendario suscriptible (iCal/.ics) Nuevo. Pull. El usuario añade una URL a su Google Calendar / Outlook / Apple Calendar y ve las fechas clave (fin de plazo, exámenes, publicaciones esperadas) sincronizadas automáticamente. Cada vez que el sistema detecta una fecha nueva, aparece en el calendario sin acción del usuario. --- ## 3. Matriz fase × canal × público Esta es la **configuración por defecto**. Cada usuario puede sobrescribirla con reglas propias. | Fase | Email diario | Email inmediato | Dashboard | iCal | |---|---|---|---|---| | 1. OEP | ✓ | — | ✓ | — | | 2. Bases | ✓ | ✓ (academia, contenidos) | ✓ | ✓ (fecha publicación) | | 3. Presentación solicitudes | ✓ | ✓ (academia, comercial) | ✓ | ✓ (fin de plazo) | | 4. Lista provisional admitidos | ✓ | ✓ (opositores inscritos) | ✓ | ✓ (fin subsanación) | | 5. Lista definitiva admitidos | ✓ | ✓ (opositores inscritos) | ✓ | — | | 6. Fecha/lugar examen | ✓ | ✓ (TODOS los suscritos) | ✓ | ✓ (fecha examen) | | 7. Desarrollo ejercicios | ✓ | — | ✓ | ✓ (fechas sucesivos) | | 8. Resultados | ✓ | ✓ (opositores participantes) | ✓ | — | | 9. Relación aprobados | ✓ | ✓ (academia, opositores) | ✓ | — | | 10. Nombramiento | ✓ | — | ✓ | ✓ (toma posesión) | Modificadores: | Modificador | Email diario | Email inmediato | Dashboard | iCal | |---|---|---|---|---| | Corrección de errores en bases | ✓ | ✓ (siempre) | ✓ | — | | Ampliación de plazo | ✓ | ✓ (siempre) | ✓ | ✓ (nueva fecha fin) | | Composición del tribunal | ✓ | — | ✓ | — | | Plantilla de respuestas | ✓ | ✓ (opositores) | ✓ | ✓ (fin alegaciones) | --- ## 4. Reglas de notificación configurables El sistema permite reglas a tres niveles: ### Nivel 1: Configuración por categoría/usuario (interfaz simple) El usuario configura desde el dashboard, por cada categoría a la que está suscrito: - Email diario: ¿con qué frecuencia? (diario / semanal / nunca) - Email inmediato: ¿para qué fases? (checkboxes) - Calendario iCal: ¿qué tipos de fecha? (fin plazo / examen / nombramiento) ### Nivel 2: Reglas avanzadas (interfaz YAML para admins) Para academias y equipos. Reglas tipo "si pasa X, notifica a Y por Z": ```yaml - nombre: "Bases TAG Madrid → equipo contenidos" condicion: fase: bases administracion: ayto_madrid cuerpo: tag accion: canal: email_inmediato destinatarios: ["contenidos@academia.es"] asunto_template: "🟢 Nuevas bases TAG Madrid - revisar temario" - nombre: "Diff temario >20% → reescribir materiales" condicion: tipo: diff_temario_calculado porcentaje_cambio_min: 20 accion: canal: email_inmediato + dashboard_alerta destinatarios: ["coordinacion@academia.es"] - nombre: "OEP en CCAA estratégica sin curso" condicion: fase: oep ccaa: [castilla_y_leon, c_valenciana, andalucia] sin_curso_activo: true accion: canal: email_inmediato destinatarios: ["direccion@academia.es"] asunto_template: "💡 Oportunidad: OEP en {ccaa} sin curso abierto" ``` ### Nivel 3: Reglas del sistema (no configurables) Algunas siempre se disparan, son inviolables: - Si un proceso lleva > N meses huérfano, alertar al admin del sistema. - Si una regla genera > 100 notificaciones al día, suspender por protección (probable bug en la condición). - Si un usuario marca > 5 "Falso positivo" en notificaciones inmediatas del mismo tipo en 24h, suspender ese tipo de notificación inmediata para él (auto-protección anti-spam). --- ## 5. Archivos de esta entrega | # | Archivo | Qué contiene | |---|---|---| | 05 | `05_README_notificaciones.md` | Este documento (mapa general) | | 06 | `06_fases_extendido.yaml` | Reemplazo de `01_fases.yaml` con las 10 fases | | 07 | `07_db_alertas_y_reglas.sql` | Tablas SQL para alertas, reglas y suscripciones a procesos | | 08 | `08_email_alerta_template.html` | Plantilla del email inmediato | | 09 | `09_dashboard_especificacion.md` | Pantallas, vistas y endpoints del dashboard | | 10 | `10_calendario_ics.py` | Generador de calendarios .ics suscriptibles | --- ## 6. Cómo se integra con lo anterior Esta entrega **no rompe** ninguna de las anteriores. Las extiende: - **`01_fases.yaml`** se sustituye por **`06_fases_extendido.yaml`**. El cambio es retrocompatible: las fases antiguas (oep, bases, apertura, subfase) tienen alias hacia las nuevas. - **`03_db_procesos_schema.sql`** se complementa con **`07_db_alertas_y_reglas.sql`**. Las tablas nuevas referencian las existentes (`procesos`, `eventos_proceso`, `usuarios`). - **El parser de bases** (`04_parser_bases.py`) y el **diff de temarios** (`04_diff_temarios.py`) ya disparan eventos que el motor de notificaciones recoge. - **El email diario** (`02_email_template.html`) sigue saliendo cada tarde. La diferencia es que ahora hay un segundo canal de email inmediato para los eventos críticos. --- ## 7. Orden de implementación recomendado **Sprint 1 (urgente)**: dashboard mínimo + email inmediato para fase 2 (bases). Es lo que más valor añade para una academia, lo que justifica inversión en producto frente a la competencia. **Sprint 2**: reglas configurables (nivel 1, interfaz simple) + calendario .ics. Permite al usuario adaptarlo a su flujo. **Sprint 3**: reglas avanzadas (nivel 2, YAML) + matriz completa de canales para todas las fases. **Sprint 4**: integración con el bucle de mejora continua. Las notificaciones también alimentan el feedback (botón "esto no debió notificarme" → regla nueva para silenciar). --- ## 8. Métricas a vigilar tras desplegar - **Tasa de apertura del email inmediato**: si está bajo 50 %, es spam. Subir el umbral de qué eventos disparan inmediato. - **Tasa de "silenciar" en alertas inmediatas**: si más del 10 % de los usuarios silencia el mismo tipo, la regla por defecto está mal. - **Tiempo medio entre evento detectado y email enviado**: objetivo < 15 minutos para fase 2 y 3, < 60 minutos para el resto. - **Visitas al dashboard por usuario y semana**: si baja, indica desinterés. Si sube, indica que el dashboard se está convirtiendo en herramienta de trabajo (objetivo). - **% de procesos seguidos con calendario .ics suscrito**: indicador de adopción avanzada.