carlostellocba/admin-edu-space
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
a188c3bd8fde2447f0bdba4edd046ba70d52049e
admin-edu-space/ROADMAP_MVP.md
T

14 KiB
Raw Blame History

ROADMAP MVP — Sistema Integral UniCABA

Gestión de Espacios Áulicos, Actividad de Cursada y Seguimiento Académico

Institución: Universidad de la Ciudad de Buenos Aires (UniCABA)
Versión: 3.1.0
Fecha de Actualización: 23 de Septiembre de 2026
Rama Base: mvp

🗺️ Visión del Proyecto

Construir y evolucionar la plataforma de gestión académica y espacial de UniCABA hacia un sistema integral de clase universitaria, desacoplado en una arquitectura Backend RESTful (Python/Flask) + Frontend BFF (Node.js/Express/Nunjucks), capaz de gobernar tanto los espacios físicos de la sede central como la dinámica áulica del campus virtual, garantizando una experiencia fluida para Administradores, Bedelía, Docentes y Estudiantes.

📊 Estado Global de Progreso

Fase 0: Desacople y Arquitectura Base    [████████████████████] 100% (Completado)
Fase 1: Paridad Legacy y Estabilización  [████████████████████] 100% (Completado)
Fase 2: Co-docencia y Matriz Conflictos  [████████████████████] 100% (Completado)
Fase 3: Hitos Evaluativos y Calificaciones[████████████████████] 100% (Completado)
Fase 4: UI/UX Drag & Drop e Impersonación[████████████████████] 100% (Completado)
Fase 5: Integración Auth, Email & Moodle [████████████████████] 100% (Completado)
Fase 5.1: Bedelía UX, ABMs y Purga Datos [████████████████████] 100% (Completado)
Fase 6: Despliegue Producción e Infraest.[███████░░░░░░░░░░░░░]  35% (En Curso)

🚀 Detalle de Fases y Estadios

Fase 0: Desacople y Arquitectura Base ✅ (Completada)

  • Objetivo: Separar el monolito Jinja2 legacy en dos servicios independientes de alto rendimiento.
  • Entregables:
    • Creación del Backend Flask como API REST pura bajo /api/v1/ retornando exclusivamente JSON.
    • Implementación del Frontend BFF en Node.js + Express con renderizado de plantillas mediante Nunjucks.
    • Autenticación desacoplada mediante JWT (access_token) transportado en Cookie HttpOnly segura.
    • Pipeline de seguridad SecurityFilterChain con cabeceras de blindaje OWASP y rate limiting dinámico.
    • Cliente HTTP Axios centralizado con inyección automática de Bearer token y manejo de sesiones.

Fase 1: Paridad Legacy, Estabilización de Virtualidad y BFF Core ✅ (Completada)

  • Objetivo: Alcanzar paridad funcional total con la versión legacy, subsanando defectos críticos de virtualidad y dotando de interfaz específica a cada rol.
  • Entregables:
    • Importador de Google Sheets Corregido:
      • Eliminación de la colisión de horarios en el aula virtual única (Campus Virtual · VIRTUAL).
      • Incremento de reservas registradas de 363 a 643 (incorporando 280 clases virtuales que se descartaban).
      • Generación y persistencia automática de enlaces de Google Meet institucional por comisión y reserva.
    • Dashboards Especializados por Rol:
      • Dashboard interactivo para Bedelía (aulas físicas, salas virtuales, aprobaciones pendientes).
      • Dashboard interactivo para Docente (clases del día, comisiones, enlaces directos a Meet).
      • Dashboard interactivo para Alumno (brújula de cursada "¿Dónde curso hoy?", hitos y calendario).
      • Cockpit institucional para Admin (métricas de capacidad, auditoría RBAC, demanda mensual).
      • Selector dinámico de vista previa / roles en tiempo real (?role=...).
    • Cartelera del Día (today_schedule):
      • Grilla temporal por bloques horarios (07:00 a 21:00 hs) con indicadores físicos y virtuales.
      • Filtro dinámico para ocultar clases virtuales (hide_virtual=1) y segmentación por piso o turno.
    • Acople de Ficha de Reserva (schedule.view_reservation):
      • Ruteo en BFF (/schedule/view_reservation?id=... y /view/:id).
      • Endpoint REST /api/v1/reservations/<id> con enriquecimiento relacional (aula, comisión, docente).
      • Soporte para modificar reserva (edit_reservation) con selectores en cascada, confirmación y cancelación.
    • Gestión de Comisiones (admin/commissions_list):
      • Botón y modal interactivo + Nueva Comisión (#modalAddCommission).
      • Vinculación obligatoria y explícita a la Asignatura / Materia, indicando cuatrimestre, año lectivo, turno, docente a cargo, cupo y enlace virtual.
      • Visualización en tabla de la materia vinculada con su código y carrera asociada.

Fase 2: Co-docencia, Matriz de Conflictos y Regla Diaria ✅ (100% Completado)

  • Objetivo: Implementar las reglas de negocio académicas complejas para asignación de cátedras y cursada de alumnos.
  • Estadios:
    1. Estadio 2.1 — Modelo de Co-docencia:
      • Tabla relacional commission_teachers para soportar múltiples docentes por comisión (titulares, adjuntos, ayudantes).
      • Endpoints /api/v1/commissions/<id>/teachers para asociar y desvincular docentes de cátedra.
      • Adaptación de vistas de Bedelía y Comisiones para visualizar el equipo docente completo.
    2. Estadio 2.2 — Matriz de Conflictos y Validación:
      • Validación estricta de conflicto físico: bloqueo de doble asignación de aula en mismo día y horario.
      • Validación de conflicto docente: detección de superposición horaria del profesor, con soporte de excepción justificada cuando la comisión cuenta con co-docencia.
      • Validación de aforo: bloqueo cuando la cantidad de alumnos excede la capacidad del aula física.
    3. Estadio 2.3 — Regla de Restricción Diaria del Alumno:
      • Validación al matricular: un alumno no puede cursar dos asignaturas regulares en el mismo día calendario.
      • Excepción parametrizable: autorización automática si al menos una de las materias es un "curso corto" (is_short_course) o si existe autorización manual de Bedelía (allow_same_day_exception).

Fase 3: Gestión de Hitos Evaluativos y Libro de Calificaciones 📅 (Completada)

  • Objetivo: Proveer al cuerpo docente y estudiantil el seguimiento completo de instancias evaluativas.
  • Estadios:
    1. Estadio 3.1 — Calendario de Evaluación por Comisión:
      • Programación de parciales, recuperatorios, entregas de trabajos prácticos y exámenes finales.
      • Notificaciones preventivas en el dashboard del alumno con cuenta regresiva para exámenes.
    2. Estadio 3.2 — Libro de Calificaciones (Gradebook):
      • Matriz de carga rápida de notas para docentes con autoguardado asíncrono.
      • Consulta individualizada de calificaciones y retroalimentaciones pedagógicas para alumnos.
      • Cierre de actas de regularidad y promoción para Bedelía.

Fase 4: UI/UX Avanzada para Bedelía & Modo Impersonación 🖥️ ✅ (100% Completado)

  • Objetivo: Dotar a la oficina de Bedelía y a la Administración de herramientas interactivas de última generación.
  • Estadios:
    1. Estadio 4.1 — Grilla Semanal Interactiva (Drag-and-Drop):
      • Interfaz tipo TimeGrid interactiva con arrastre de comisiones para asignación rápida de aulas y turnos (FullCalendar editable: true + droppable: true).
      • Panel lateral de comisiones pendientes de aula (unassigned_commissions) con arrastre directo hacia la grilla.
      • Detección visual en tiempo real de aulas ocupadas, colisiones horarias, aforo insuficiente o choques de docentes con reversión automática y mensajes de alerta descriptivos vía POST /api/v1/reservations/drag-update.
    2. Estadio 4.2 — Modo Impersonación del Superadmin:
      • Funcionalidad de login as con soporte para cabecera X-Impersonate-User en Backend Flask (jwt_required) y Frontend BFF (authMiddleware).
      • Botón directo de impersonación en la lista administrativa de usuarios (admin/users/list.html).
      • Banner de advertencia visual permanente en la barra superior con indicador de usuario impersonado y botón de salida inmediata hacia la sesión administrativa.
      • Trazabilidad obligatoria y estricta en el registro de auditoría (audit_logs) con eventos IMPERSONATE_START e IMPERSONATE_END.
    3. Estadio 4.3 — Integración del Optimizador Genético:
      • Acople del motor heurístico de algoritmos genéticos a la base de datos real con cálculo de turnos reales (Mañana, Tarde, Vespertino).
      • Prevención de choques en guardado masivo con persistencia directa en base de datos (POST /api/genetic/apply-optimization).

Fase 5: Integración Auth, Email & Moodle Backend 🛡️ ✉️ 🎓 ✅ (100% Completado)

  • Objetivo: Centralizar la gestión de credenciales, autenticación híbrida, motor transaccional de correo y sincronización bidireccional asíncrona con Moodle 4.1 con tolerancia total a fallos.
  • Épicas Entregadas:
    1. Épica 1 — Panel de Configuración Global (Perfil ADMIN):
      • Módulo SMTP: UI/API dinámica con host, puerto, usuario, seguridad (TLS/SSL/NONE) y contraseña cifrada con Fernet (/admin/settings).
      • Módulo SSO: Toggles para habilitar/deshabilitar Login Local, Google OAuth 2.0 y Moodle SSO en base de datos.
      • Credenciales OAuth & Moodle: Client ID/Secret de Google y URL de Servidor / Token Web Services de Moodle 4.1.
    2. Épica 2 — Infraestructura Asíncrona y Caché:
      • Capa de Caché Híbrida: CacheService con integración Redis y fallback en memoria/TTL.
      • Cola Persistente MoodleSyncTask con reintentos exponenciales y Dead Letter Queue (DLQ).
      • Panel de monitorización de cola con métricas en tiempo real, botón de "Forzar Sincronización Inmediata" y reintento masivo de tareas fallidas.
    3. Épica 3 — Autenticación Híbrida (SSO & Local Tolerante a Fallos):
      • Login Local: Fallback con contraseña nativa y contingencia para ADMIN cuando está desactivado para usuarios generales.
      • Google OAuth 2.0: Restricción arquitectónica de dominios (@unicaba.edu.ar, @lasalle.edu.ar) inspirada en AlumnosLS.
      • Moodle Delegated Login: Autenticación contra /login/token.php de Moodle 4.1 con mapeo inicial de roles (Admin/Docente/Alumno) y desacople local para cambios posteriores por Bedelía/Admin.
    4. Épica 4 — Adaptadores Moodle 4.1 (Bidireccional):
      • Cliente REST Moodle 4.1 (moodle_client) con soporte para core_user_create_users, core_user_update_users, core_user_get_users, enrol_manual_enrol_users, enrol_manual_unenrol_users, core_enrol_get_enrolled_users, core_role_assign_roles, core_role_unassign_roles.
      • Encolado automático y no bloqueante al crear o editar usuarios en Edu-Space.
    5. Épica 5 — Motor de Notificaciones (Email Dinámico):
      • Transporte SMTP dinámico (email_service) instanciado en tiempo de ejecución leyendo credenciales descifradas de la BD.
      • Notificaciones transaccionales automáticas para profesores (asignación de comisiones, cronogramas de exámenes y alertas de sistema).

Fase 5.1: Bedelía UX, ABMs y Purga Segura de Datos 🏛️ ⚡ ✅ (100% Completado)

  • Objetivo: Optimizar de punta a punta la experiencia de usuario de Bedelía, dotar de ABMs completos a las entidades académicas y asegurar la purga de datos sin comprometer identidades ni claves foráneas.
  • Entregables:
    1. Circuito Ágil de Bedelía:
      • Flujo de asignación ágil: de lista de comisiones (/admin/commissions_list) a reserva de aula (/schedule/add_reservation?commission_id=...) con 1 clic.
      • Sincronización en cascada de selectores (Edificio -> Piso -> Aula) con detección de modalidad física/virtual y aforo.
      • Conexión de reservas con comisiones activas en vivo vía API REST desacoplada (fin de mocks estáticos).
      • Creación de aulas con vinculación consistente de sede y tipología.
    2. ABMs Académicos Completos:
      • ABM de Carreras (/admin/careers_list) con protección ante asignaturas existentes (soft-deactivation).
      • ABM de Asignaturas (/admin/subjects_list) con vinculación por carrera y mitigación de desvinculación forzada.
      • ABM de Comisiones (/admin/commissions_list) con asignación directa de profesores, turnos y cupos.
    3. Purga Segura de Datos Académicos:
      • Modal de confirmación interactivo en frontend (#purgeConfirmModal) con feedback visual y prevención de borrado accidental.
      • Secuencia de purga backend en estricto orden de integridad referencial (respetando Foreign Keys).
      • Preservación garantizada de usuarios y roles RBAC ante reseteos de datos de cursada.

Fase 6: Producción Institucional, CI/CD y Despliegue 🏢 (En curso)

  • Objetivo: Puesta en marcha definitiva en la infraestructura de servidores de UniCABA.
  • Estadios:
    1. Estadio 6.1 — Despliegue e Infraestructura:
      • docker-compose.yml productivo orquestando Flask (Gunicorn), Node.js BFF (PM2) y PostgreSQL 15.
      • Proxy inverso Nginx con certificados SSL/TLS y compresión Brotli/Gzip.
    2. Estadio 6.2 — Sincronización Continua Moodle:
      • Sincronización automática de aulas virtuales y usuarios con Moodle 4.1 institucional (10.0.0.207).
      • Automatización de workers persistentes (systemd / supervisor) para el procesamiento continuo de la cola.
    3. Estadio 6.3 — Pruebas de Carga y Hardening:
      • Pruebas de estrés de concurrencia en días pico de inicio de cuatrimestre (10.000 solicitudes simultáneas).

📈 Criterios de Aceptación del MVP

  1. Zero Colisiones Físicas: Imposibilidad absoluta de asignar dos materias simultáneas a una misma aula física.
  2. Virtualidad Fluida: Acceso con un clic a reuniones virtuales válidas para el 100% de las comisiones remotas.
  3. Roles Seguros: Separación total de permisos donde ningún alumno o docente acceda a configuración global ni a datos privados de otras comisiones.
  4. Respuesta Sub-segundo: Carga de carteleras y calendarios en menos de 300 ms en el BFF Node.js.
Reference in New Issue View Git Blame Copy Permalink