# Registro de Cambios — Sprint UX/Consistencia (19/06/2026)

**Rama:** `features/MirkoALS2`
**Commit:** `e700c85`
**Autor:** Mirko Lazarte

---

## ¿Qué se hizo y por qué?

Este sprint no agrega funcionalidades nuevas; corrige problemas de experiencia
de usuario y consistencia visual que afectaban a todos los roles del sistema
(ADMIN, SECRETARIA, DOCENTE, DIRECCION, MKT). Los cambios son seguros: no
modifican la base de datos, no alteran endpoints del backend y no rompen
funcionalidades existentes.

---

## Cambio 1 — Abrir materias en múltiples carreras a la vez

**Módulo:** Gestión de Carreras → Ofertas de Asignaturas
**Archivo:** `frontend/src/pages/Carreras.tsx`

### El problema

Cuando un administrador quería abrir la misma materia (por ejemplo *Matemáticas I*)
para las cuatro carreras del período vigente, tenía que repetir el formulario
cuatro veces por separado. Además, el drawer no mostraba en ningún lugar en qué
carrera ni en qué período estaba trabajando, lo que generaba confusión y errores.

### Lo que se cambió

1. **Encabezado de contexto en el drawer.** Ahora el formulario muestra siempre:
   > Abrir materia en **Informática** · Semestre I 2026

2. **Sección "También abrir en otras carreras".** Aparece debajo del formulario
   principal. Muestra un checkbox por cada carrera activa del sistema. Al marcar
   una o más, la materia se abre en todas al mismo tiempo en una sola operación.

3. **Botón "Seleccionar todas las carreras".** Marca todos los checkboxes de una
   vez para el caso más común.

4. **Badge `+N` en el acordeón.** Mientras el drawer está abierto, el encabezado
   del acordeón de la carrera actual muestra cuántas carreras adicionales están
   seleccionadas: `Informática [+3]`.

5. **Botón de guardar dinámico.** El texto del botón cambia según la selección:
   - Sin extras seleccionados → `Abrir materia`
   - Con 3 extras → `Abrir en 4 carreras`

6. **Toast de confirmación.** Al terminar informa la cantidad real de carreras
   procesadas: `Materia abierta en 4 carreras`.

---

## Cambio 2 — Módulo Docentes accesible desde la interfaz para ADMIN

**Módulo:** Gestión de Docentes
**Archivos:** `frontend/src/pages/Docentes.tsx`, `frontend/src/routes/AppRouter.tsx`,
`frontend/src/components/Sidebar.tsx`

### El problema

La página de gestión de docentes (`Docentes.tsx`) estaba completamente implementada
con funcionalidad CRUD completa y opción de reseteo de contraseña, pero no existía
ninguna ruta registrada en el router ni ningún ítem en el menú lateral. El ADMIN
no tenía forma de llegar a esa pantalla desde la interfaz.

### Lo que se cambió

- Se registró la ruta `/docentes` en `AppRouter.tsx` apuntando al componente
  `Docentes`.
- Se agregó el ítem **"Docentes"** (ícono: birrete académico) en el menú lateral
  `Sidebar.tsx`, visible únicamente para el rol `ADMIN`.

No se modificó nada del componente `Docentes.tsx` en sí; solo se lo conectó.

---

## Cambio 3 — Etiquetas claras en los botones de descarga de informes

**Módulo:** Asistencias (secretaría y vista general)
**Archivos:** `frontend/src/pages/Asistencias.tsx`,
`frontend/src/pages/secretaria/AsistenciasSecretaria.tsx`

### El problema

El botón de descarga de reportes mostraba el mismo texto `Historial / Informe PDF`
sin importar cuál de los tres documentos disponibles se iba a generar:
- Lista de clase del día
- Informe mensual de asistencias
- Historial de bajas / abandonos

El usuario no sabía qué iba a descargar hasta abrirlo.

### Lo que se cambió

El label del botón ahora refleja el tipo exacto de documento:
- `Descargar lista de clase`
- `Descargar informe mensual`
- `Descargar historial de bajas`

El cambio es idéntico en ambos archivos (`Asistencias.tsx` y
`AsistenciasSecretaria.tsx`).

---

## Cambio 4 — Formato de fechas unificado en todo el frontend

**Archivos creados:** `frontend/src/utils/format.ts`
**Archivos modificados:** `Periodos.tsx`, `AsistenciasSecretaria.tsx`,
`HorarioDocente.tsx`, `Asistencias.tsx`, `Matriculaciones.tsx`

### El problema

Cinco páginas distintas definían cada una su propia función `formatFecha` con
implementaciones ligeramente distintas. Algunas usaban `toLocaleDateString` con
locale en inglés, otras en español, y dos páginas (`Asistencias.tsx` y
`Matriculaciones.tsx`) mostraban directamente el string ISO crudo `2026-06-19`
sin formatear.

El resultado: la misma fecha podía verse como `Jun 19, 2026`, `19 de junio de 2026`
o `2026-06-19` según en qué pantalla estuvieras.

### Lo que se cambió

- Se creó `frontend/src/utils/format.ts` con la función `formatFecha(iso)`.
  Convierte cualquier string `"YYYY-MM-DD"` al formato `"DD/MM/YYYY"`. Si el
  valor es nulo, indefinido o inválido, devuelve `"—"` en lugar de romper.
- Se eliminaron las cinco definiciones locales.
- Todas las páginas ahora importan y usan la misma función.

Consultar `docs/utils-frontend.md` para ver cómo usarla.

---

## Cambio 5 — Colores de estado unificados en todo el frontend

**Archivo creado:** `frontend/src/utils/colors.ts`
**Archivos modificados:** `Asistencias.tsx`, `AsistenciasSecretaria.tsx`,
`Ofertas.tsx`, `Periodos.tsx`, `NivelesAcademicos.tsx`, `Grupos.tsx`,
`Docentes.tsx`, `InscritosMKT.tsx`, `InscripcionMKT.tsx`

### El problema

Cada página hardcodeaba sus propios colores Tailwind para los badges de estado.
El mismo concepto "Inactivo" podía ser gris en una pantalla y rojo en otra.
"Activo" era `green-100 text-green-800` en algunos archivos y `emerald-50
text-emerald-700 border-emerald-200` en otros. Había al menos cuatro
implementaciones distintas del mismo badge.

### Lo que se cambió

- Se creó `frontend/src/utils/colors.ts` como fuente única de verdad para todos
  los colores de estado del sistema.
- Las páginas afectadas ya no tienen colores hardcodeados; llaman a las funciones
  del util.

Funciones disponibles:

| Función | Cuándo usarla |
|--------|--------------|
| `colorActivo(activo)` | Catálogos genéricos (Activo / Inactivo) |
| `colorEstadoAsistencia(nombre)` | Presente / Ausente / Tardanza / Justificado |
| `colorEstadoEstudiante(nombre)` | Activo / Egresado / Abandono / Suspendido |
| `colorEstadoInscripcion(nombre)` | Activa / Baja / Pendiente / Aprobada / Reprobada |
| `colorTurno(nombre)` | Mañana / Tarde / Noche |
| `colorModalidad(nombre)` | Semestral / Modular / Anual |

Consultar `docs/utils-frontend.md` para ejemplos de uso.

---

## Archivos nuevos creados

| Archivo | Propósito |
|---------|-----------|
| `frontend/src/utils/format.ts` | Función única para formatear fechas en toda la app |
| `frontend/src/utils/colors.ts` | Paleta semántica de colores de estado para badges |
| `docs/utils-frontend.md` | Documentación de uso de los dos utils anteriores |
| `BD/seed_prueba_20260619.sql` | Script SQL con datos de prueba para desarrollo local |

---

## Cómo verificar los cambios

1. Iniciar el frontend: `cd frontend && npm run dev`
2. Ingresar como ADMIN y verificar que **Docentes** aparece en el menú lateral.
3. En Carreras → abrir el formulario de nueva oferta y verificar el encabezado
   de contexto y los checkboxes de carreras adicionales.
4. En Asistencias → verificar que los botones de descarga tienen nombres
   distintos según el tipo de reporte.
5. Comparar fechas entre Períodos, Asistencias y Matriculaciones → deben verse
   todas como `DD/MM/YYYY`.
6. Revisar badges de estado en Grupos, Docentes, Ofertas y Períodos → deben
   tener el mismo color para el mismo concepto en todas las pantallas.
