docs: actualizar CHANGELOG_SESSION.md con Fases 3, 4, 5, copia robusta y correcciones de autenticacion
This commit is contained in:
@@ -41,3 +41,39 @@ Anteriormente, si un cliente perdía su archivo de configuración `config.json`
|
||||
- **TypeError en el Tray Icon**: Se resolvió un error de casteo en PyQt6 (`TypeError: unable to convert a C++ 'QSystemTrayIcon::ActivationReason'`) al reabrir el panel del agente desde el área de notificaciones de Windows.
|
||||
- **Colisiones en Cliente ID**: Se corrigió el algoritmo de generación del código de cliente (`CLIENT-XXXX`). En lugar de usar un recuento dinámico de la tabla (que colisionaba si se borraban clientes intermedios), ahora se calcula usando el ID máximo de la base de datos más uno (`max(id) + 1`).
|
||||
- **Historial en Caliente**: Ahora el backend actualiza de forma automática el estado (`SUCCESS` / `FAILED`) y la fecha (`last_run_at`) de los trabajos en la base de datos al finalizar exitosamente la subida de todos sus bloques.
|
||||
|
||||
---
|
||||
|
||||
## 📅 5. Planificación Calendarizada Avanzada (Cron y Calendario Proxmox) — Fase 3
|
||||
|
||||
Se ha ampliado el evaluador de tiempos de ejecución (`is_job_due` en el Agente de Windows) para soportar planificaciones complejas:
|
||||
- **Expresiones Cron**: Admite la sintaxis estándar de 5 campos (minuto, hora, día de mes, mes, día de semana) para disparos programados de forma precisa (ej. `0 2 * * *`).
|
||||
- **Cadenas de Calendario de Proxmox (PBS)**: Permite programar rangos específicos de días y horas (ej. `mon..fri 22:00` o `sat,sun 18:00`).
|
||||
- **Simulación Histórica**: El agente evalúa si ocurrió algún disparo agendado en el intervalo comprendido entre la última ejecución registrada y la hora actual del sistema, eliminando riesgos de omisión.
|
||||
|
||||
---
|
||||
|
||||
## 📊 6. Historial de Ejecuciones, Métricas y Telemetría (Job Runs) — Fase 4
|
||||
|
||||
Se ha estructurado un motor de auditoría centralizado para las corridas de backup:
|
||||
- **Base de Datos**: Creación de la tabla `job_runs` para registrar marcas temporales y métricas de cada corrida (archivos escaneados, copiados, omitidos, cantidad de errores, bytes transferidos y resumen de errores).
|
||||
- **Notificaciones del Agente**: El daemon notifica el inicio de la corrida (`POST /api/jobs/{id}/runs/start`) obteniendo un identificador de corrida, y reporta su estado y métricas al culminar (`POST /api/jobs/{id}/runs/{run_id}/complete`).
|
||||
- **Panel Web**: Incorporación de un botón interactivo de historial (icono de reloj) que despliega un modal detallando las corridas previas, duración y su rendimiento de transferencia.
|
||||
|
||||
---
|
||||
|
||||
## 📁 7. Copia Local Duplicada y Copia Robusta — Fase 5 (Fusión con Karen's Replicator)
|
||||
|
||||
Implementación del almacenamiento redundante local o de red:
|
||||
- **Destino Adicional**: Permite configurar una ruta física local o recurso de red UNC (`\\Servidor\Recurso`) para duplicar el backup en caliente.
|
||||
- **Réplica Exacta**: Si se activa la eliminación de huérfanos, el agente remueve archivos y subcarpetas vacías del destino local si estos ya no existen en el origen.
|
||||
- **Copia Robusta (Estilo Karen's Replicator v3.5.0)**: Para evitar corromper archivos locales ante caídas del sistema o cortes de energía, los archivos se escriben primero con una extensión temporal `.tmp` y se renombran a su nombre final solo cuando la copia de `shutil` se completa exitosamente.
|
||||
- **Interfaz PyQt**: Agregado el campo de "Copia Local Adicional" con un explorador nativo de directorios de Windows para facilitar la configuración del cliente.
|
||||
|
||||
---
|
||||
|
||||
## 🛠️ 8. Corrección de Autenticación y Dependencias
|
||||
|
||||
- **Corrupción de Módulo `jwt`**: Se resolvió una colisión de dependencias en Python donde instalar el paquete genérico `jwt` en lugar de `PyJWT` rompía el método `jwt.encode`. Se forzó la reinstalación limpia de `pyjwt` en el entorno virtual.
|
||||
- **Reset de Admin por Defecto**: Añadida lógica de restablecimiento forzado de contraseña en el inicio del backend (`main.py`) para asegurar que el usuario administrador (`admin@oneverdrive.local`) y su contraseña (`Admin1234!`) se impongan y validen automáticamente en entornos de desarrollo/pruebas.
|
||||
|
||||
|
||||
Reference in New Issue
Block a user