Miguel
/
ParamManagerScripts
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity
ParamManagerScripts/backend/script_groups/EmailCrono/.doc/MemoriaDeEvolucion.md

5.7 KiB
Raw Blame History

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.