84 lines
5.7 KiB
Markdown
84 lines
5.7 KiB
Markdown
# Memoria de Evolución - Procesador de Emails a Cronología
|
|
|
|
## Descripcion de los scripts Procesador de Emails a Cronología
|
|
Este script procesa archivos de correo electrónico (.eml) para extraer su contenido, gestionar adjuntos y generar un archivo Markdown que presenta los mensajes en orden cronológico inverso.
|
|
|
|
Lógica Principal:
|
|
|
|
Beautify: Carga reglas de embellecimiento de texto desde config/beautify_rules.json para limpiar el contenido de los correos.
|
|
Descubrimiento: Busca todos los archivos .eml en el directorio de trabajo configurado.
|
|
|
|
Procesamiento Individual:
|
|
Itera sobre cada archivo .eml encontrado.
|
|
Utiliza utils.email_parser.procesar_eml para extraer metadatos (fecha, asunto, remitente, destinatarios), contenido del cuerpo y guardar los archivos adjuntos en la carpeta especificada.
|
|
Calcula un hash para cada mensaje para detectar duplicados.
|
|
|
|
Si un mensaje es nuevo (no duplicado):
|
|
|
|
Aplica las reglas de BeautifyProcessor al contenido del cuerpo.
|
|
Añade el mensaje procesado a una lista.
|
|
|
|
Ordenación: Ordena la lista de mensajes únicos por fecha, del más reciente al más antiguo.
|
|
|
|
Generación de Índice: Crea una sección de índice en formato Markdown con enlaces internos a cada mensaje.
|
|
Salida Markdown: Escribe el índice seguido del contenido formateado en Markdown de cada mensaje en el archivo de salida configurado (ej. cronologia.md).
|
|
|
|
|
|
## 2025-08-08 — Inversión de directorios (entrada/salida)
|
|
|
|
- Decisión: Alinear con la guía `backend_setup.md` para que:
|
|
- `working_directory` sea el directorio de salida (resultado), donde se escribe `cronologia.md` y se guardan los adjuntos.
|
|
- `level3.input_directory` sea el directorio de entrada donde se leen los `.eml`.
|
|
- Cambios:
|
|
- `esquema_work.json`: se renombra `output_directory` → `input_directory` y se actualizan `title`/`description`.
|
|
- `x1.py`:
|
|
- Lee `level3.input_directory` como entrada.
|
|
- Escribe `cronologia_file` y `attachments_dir` dentro de `working_directory`.
|
|
- Crea directorios de salida si no existen.
|
|
- Se corrigen lints (E402 y líneas largas) sin alterar lógica.
|
|
- Impacto:
|
|
- Los `work_dir.json` existentes deben actualizar la clave a `input_directory`.
|
|
- No hay cambios en claves de `level2` (`cronologia_file`, `attachments_dir`).
|
|
|
|
## 2025-08-08 — Manejo de imágenes (inline y adjuntas) y embebido en Markdown
|
|
|
|
- Decisión:
|
|
- Capturar imágenes tanto adjuntas (`attachment`) como inline (`inline`/sin `Content-Disposition`).
|
|
- Guardar las imágenes en el directorio de adjuntos configurado y además copiar a `adjuntos/cronologia` dentro del `working_directory`.
|
|
- Incrustar en el Markdown enlaces de Obsidian con ruta absoluta al archivo copiado en `adjuntos/cronologia` usando la sintaxis de embed `![[...]]` bajo una sección `### Imágenes` por mensaje.
|
|
- Cambios:
|
|
- `utils/attachment_handler.py`: nueva función `guardar_imagen` que genera nombres a partir de `Content-ID` o hash y evita colisiones por contenido; refactor de hashing de contenido.
|
|
- `utils/email_parser.py`:
|
|
- Se amplía la firma de `procesar_eml`/`procesar_eml_interno` para recibir `dir_adjuntos_cronologia` y copiar allí las imágenes.
|
|
- Se manejan imágenes en partes `attachment` y `inline`, agregando su ruta absoluta copiada a `mensaje.imagenes_cronologia`.
|
|
- `models/mensaje_email.py`: `to_markdown()` agrega sección `### Imágenes` con `![[ruta_absoluta]]` previo a `### Adjuntos`.
|
|
- `x1.py`: crea `adjuntos/cronologia` y pasa la ruta al parser.
|
|
- Impacto:
|
|
- El `.md` resultante muestra las imágenes embebidas (Obsidian) desde rutas absolutas bajo `.../adjuntos/cronologia/...`.
|
|
- Se preserva el listado de adjuntos como enlaces `[[archivo]]`.
|
|
|
|
## 2025-08-08 — Editor web para `beautify_rules.json`
|
|
|
|
- Decisión:
|
|
- Crear un editor web simple (Flask) para visualizar/editar `config/beautify_rules.json` con CRUD básico y respaldo automático.
|
|
- Cambios:
|
|
- `x2.py`: servidor Flask con endpoints `/api/rules` (GET/POST), `/api/meta`, `/api/heartbeat` y `/_shutdown`. Valida estructura de reglas (campos requeridos, `action`/`type` permitidos) y genera backup con timestamp antes de guardar. Implementa cierre limpio y auto-cierre por inactividad (latido del cliente cada 10s; timeout configurable vía `INACTIVITY_TIMEOUT_SECONDS`, por defecto 60s).
|
|
- `templates/index.html`, `static/app.js`, `static/style.css`: interfaz para listar, reordenar por `priority`, agregar/eliminar reglas y editar campos. Incluye vista "Avanzado" con JSON crudo.
|
|
- UI: botón "duplicar" regla; ayuda contextual en el modal que explica cada `action` y sus efectos.
|
|
- Impacto:
|
|
- Edición segura de reglas con validación previa y backups incrementales.
|
|
- El servidor del editor se cierra automáticamente si no hay navegador activo.
|
|
- Facilita ajustar reglas sin tocar el archivo manualmente.
|
|
|
|
## 2025-08-08 — Mejora de persistencia de comentarios y UX de textareas
|
|
|
|
- Decisión:
|
|
- Asegurar que los comentarios de las reglas (`__comment`) se persistan siempre al guardar, aun cuando el usuario edite el JSON crudo.
|
|
- Mejorar la ergonomía visual inicial reduciendo la altura inicial de los campos "Comentario" y "Pattern" a 2 líneas, expandiéndose solo al escribir.
|
|
- Cambios:
|
|
- `static/app.js`:
|
|
- `saveAll()`: se fusiona el JSON avanzado si es válido, pero las `rules` provienen siempre del estado actual de la UI (`state.rules`). Así no se pierden los cambios de los textareas, incluyendo `__comment`.
|
|
- `ruleRow()`: `textarea` de `Comentario` y `Pattern` pasan de `rows=1` a `rows=2` y se evita el auto-resize en el render inicial (solo se aplica al tipear).
|
|
- Impacto:
|
|
- Los comentarios ya no se descartan al guardar incluso si el panel de JSON contiene modificaciones parciales o inválidas.
|
|
- La lista de reglas es más compacta pero legible, con expansión progresiva al editar. |