189 lines
16 KiB
Markdown
189 lines
16 KiB
Markdown
# 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:**
|
|
* [x] Creación del Backend Flask como API REST pura bajo `/api/v1/` retornando exclusivamente JSON.
|
|
* [x] Implementación del Frontend BFF en Node.js + Express con renderizado de plantillas mediante Nunjucks.
|
|
* [x] Autenticación desacoplada mediante JWT (`access_token`) transportado en Cookie `HttpOnly` segura.
|
|
* [x] Pipeline de seguridad `SecurityFilterChain` con cabeceras de blindaje OWASP y rate limiting dinámico.
|
|
* [x] 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:**
|
|
* [x] **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.
|
|
* [x] **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=...`).
|
|
* [x] **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.
|
|
* [x] **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.
|
|
* [x] **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:**
|
|
- [x] Tabla relacional `commission_teachers` para soportar múltiples docentes por comisión (titulares, adjuntos, ayudantes).
|
|
- [x] Endpoints `/api/v1/commissions/<id>/teachers` para asociar y desvincular docentes de cátedra.
|
|
- [x] 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:**
|
|
- [x] Validación estricta de conflicto físico: bloqueo de doble asignación de aula en mismo día y horario.
|
|
- [x] 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.
|
|
- [x] 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:**
|
|
- [x] Validación al matricular: un alumno no puede cursar dos asignaturas regulares en el mismo día calendario.
|
|
- [x] 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:**
|
|
- [x] Programación de parciales, recuperatorios, entregas de trabajos prácticos y exámenes finales.
|
|
- [x] Notificaciones preventivas en el dashboard del alumno con cuenta regresiva para exámenes.
|
|
2. **Estadio 3.2 — Libro de Calificaciones (*Gradebook*):**
|
|
- [x] Matriz de carga rápida de notas para docentes con autoguardado asíncrono.
|
|
- [x] Consulta individualizada de calificaciones y retroalimentaciones pedagógicas para alumnos.
|
|
- [x] 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):**
|
|
- [x] Interfaz tipo TimeGrid interactiva con arrastre de comisiones para asignación rápida de aulas y turnos (`FullCalendar` `editable: true` + `droppable: true`).
|
|
- [x] Panel lateral de comisiones pendientes de aula (`unassigned_commissions`) con arrastre directo hacia la grilla.
|
|
- [x] 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:**
|
|
- [x] Funcionalidad de *login as* con soporte para cabecera `X-Impersonate-User` en Backend Flask (`jwt_required`) y Frontend BFF (`authMiddleware`).
|
|
- [x] Botón directo de impersonación en la lista administrativa de usuarios (`admin/users/list.html`).
|
|
- [x] 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.
|
|
- [x] 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:**
|
|
- [x] 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).
|
|
- [x] 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):**
|
|
- [x] Módulo SMTP: UI/API dinámica con host, puerto, usuario, seguridad (TLS/SSL/NONE) y contraseña cifrada con Fernet (`/admin/settings`).
|
|
- [x] Módulo SSO: Toggles para habilitar/deshabilitar Login Local, Google OAuth 2.0 y Moodle SSO en base de datos.
|
|
- [x] 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é:**
|
|
- [x] Capa de Caché Híbrida: `CacheService` con integración Redis y fallback en memoria/TTL.
|
|
- [x] Cola Persistente `MoodleSyncTask` con reintentos exponenciales y Dead Letter Queue (DLQ).
|
|
- [x] 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):**
|
|
- [x] Login Local: Fallback con contraseña nativa y contingencia para ADMIN cuando está desactivado para usuarios generales.
|
|
- [x] Google OAuth 2.0: Restricción arquitectónica de dominios (`@unicaba.edu.ar`, `@lasalle.edu.ar`) inspirada en AlumnosLS.
|
|
- [x] 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):**
|
|
- [x] 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`.
|
|
- [x] Encolado automático y no bloqueante al crear o editar usuarios en Edu-Space.
|
|
5. **Épica 5 — Motor de Notificaciones (Email Dinámico):**
|
|
- [x] Transporte SMTP dinámico (`email_service`) instanciado en tiempo de ejecución leyendo credenciales descifradas de la BD.
|
|
- [x] Notificaciones transaccionales automáticas para profesores (asignación de comisiones, cronogramas de exámenes y alertas de sistema).
|
|
|
|
---
|
|
|
|
### Fase 5.1: Bedelía UX, Cobertura Integral de 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 todas las entidades de Espacios, Académica y Reservas, y asegurar la purga de datos sin comprometer identidades ni claves foráneas.
|
|
* **Entregables:**
|
|
1. **Circuito Ágil de Bedelía:**
|
|
- [x] Flujo de asignación ágil: de lista de comisiones (`/admin/commissions_list`) a reserva de aula (`/schedule/add_reservation?commission_id=...`) con 1 clic.
|
|
- [x] Sincronización en cascada de selectores (Edificio -> Piso -> Aula) con detección de modalidad física/virtual y aforo.
|
|
- [x] Conexión de reservas con comisiones activas en vivo vía API REST desacoplada (fin de mocks estáticos).
|
|
- [x] Creación de aulas con vinculación consistente de sede y tipología.
|
|
2. **Cobertura ABM 100% (Espacios, Académica y Reservas):**
|
|
- [x] **Ciclos Lectivos (`AcademicTerm`):** ABM completo (Crear, Editar, Activar como Ciclo Actual, Toggle Activo/Inactivo rápido y Borrado protegido con soft-deactivate ante comisiones asociadas). Endpoints `/api/v1/admin/academic-terms` y vistas en `/admin/academic_terms`.
|
|
- [x] **Aulas y Espacios Físicos/Virtuales (`Classroom`):** ABM completo (Alta, Edición de aforo y piso, Toggle rápido activo/inactivo vía `/api/v1/classrooms/<id>/toggle`, y Eliminación con validación de reservas previas). Botones y modales en lista y detalle.
|
|
- [x] **Sedes y Edificios (`Building`):** ABM completo (Crear, Editar, Toggle y Eliminar sedes físicas e institucionales).
|
|
- [x] **Carreras (`Career`):** ABM completo (`/admin/careers_list`) con protección ante asignaturas existentes (soft-deactivation).
|
|
- [x] **Asignaturas (`Subject`):** ABM completo (`/admin/subjects_list`) con vinculación por carrera y mitigación de desvinculación forzada.
|
|
- [x] **Comisiones (`Commission`):** ABM completo (`/admin/commissions_list`) con asignación directa de profesores, turnos y cupos.
|
|
- [x] **Reservas (`Reservation`):** ABM completo (Creación, Edición, Confirmación, Cancelación lógica y Eliminación definitiva / Hard Delete con `/api/v1/reservations/<id>?hard=true`).
|
|
3. **Purga Segura de Datos Académicos:**
|
|
- [x] Modal de confirmación interactivo en frontend (`#purgeConfirmModal`) con feedback visual y prevención de borrado accidental.
|
|
- [x] Secuencia de purga backend en estricto orden de integridad referencial (respetando Foreign Keys).
|
|
- [x] Preservación garantizada de usuarios y roles RBAC ante reseteos de datos de cursada.
|
|
4. **Configuración y Personalización UI:**
|
|
- [x] Panel de configuración global (`/admin/settings`) con opción para habilitar o deshabilitar el saludo superior y banner de rol en el dashboard.
|
|
5. **Inicialización y Despliegue con Base Limpia:**
|
|
- [x] Soporte `--empty-academic` / `--no-demo` en `install.sh` e `init_db.py` para inicializar el sistema con roles y usuarios intactos pero con tablas académicas y de espacios totalmente vacías para configuración desde cero.
|
|
|
|
---
|
|
|
|
### 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:**
|
|
- [x] 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.
|