Commit Graph
7 Commits
Author SHA1 Message Date
Lizandro GuarnizoandClaude Opus 5 b2e2e83fe8 feat(umind): el agente programa recordatorios, y solo para su dueño
"Avisame el 15 de marzo que vence la póliza de Acme, y todos los años" queda
programado desde la conversación, visible y cancelable en el panel. Tres tools:
programar, listar, cancelar.

El aviso vuelve por donde se pidió — Telegram a ese chat, correo a esa casilla
— o al dueño del espacio por correo y campanita. Nunca a una dirección que
dicte la conversación: eso sería un cañón de spam con destinatario libre.

Y las tools de aviso solo se le OFRECEN al modelo cuando la sesión es interna:
el chat de prueba del panel (que corre autenticado) o un canal marcado como
línea privada del dueño. En el widget público escribe cualquiera, y cualquiera
no puede programarle recordatorios ni gastarle el plan a otro. El gate está en
dos capas: la tool no se declara, y si igual la pide, el ejecutor la rechaza.

Tres detalles que se pagan una sola vez:
- El cron corre en memoria del proceso, sin lock distribuido: con dos
  instancias cada aviso saldría dos veces. El reclamo es un UPDATE condicional
  — la base ya es el árbitro, no hace falta traer otro.
- Si el servidor estuvo caído, una repetición diaria se saltea los ciclos
  perdidos en vez de disparar diez avisos viejos de golpe.
- Un fallo de SMTP devuelve el aviso a pendiente: una caída de correo no puede
  perder un vencimiento de póliza.

Una fecha sin hora se entrega a las 9, no a medianoche, que es cuando nadie
mira el teléfono.

De paso: los archivos de los espacios uMind nunca se sirven por el estático de
/uploads. El guard genérico solo sabe si hay sesión de panel, no de quién es el
archivo — salen por su endpoint, que sí valida propiedad. Cerrado por
construcción y no por acordarse.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-24 21:32:48 -05:00
Lizandro Guarnizo 7329bac898 up 2026-06-04 22:49:16 -05:00
Lizandro GuarnizoandCopilot 2779c0a15d fix: ping real de BD + campo Host en ConxDb + reactividad Alpine
Problema raíz:
1. El ping TCP usaba Servidor.IpServidor → fallaba si la BD solo escucha
   en localhost del servidor remoto (comportamiento normal en producción)
2. La reactividad Alpine v3.13 no detectaba keys nuevas en objeto vacío {}
   dentro de x-for loops, spinner nunca aparecía

Cambios:
- pkg/models/conx_db.go: nuevo campo Host (vacío = usa Servidor.IpServidor)
  + método HostEfectivo() como fuente única de verdad para host
- pkg/services/query_runner_service.go: todos los puntos (openDynamicDB,
  openDynamicDBWithName, redisConnect, mongoURI) usan c.HostEfectivo()
- rest/controllers/servidor_controller.go: PingConexion reescrito —
  primero prueba conexión real a la BD (no solo TCP), si falla prueba TCP,
  devuelve host+puerto testeado y mensajes de error descriptivos
- servidor_dashboard.html: hacerPing usa spread-replace para forzar
  reactividad + $nextTick, resultado muestra host:puerto testeado y
  mensaje de error completo en múltiples líneas

Co-authored-by: Copilot <223556219+Copilot@users.noreply.github.com>
2026-05-21 11:56:12 -05:00
Lizandro Guarnizo a44fb490f7 feat(conx_db): add nombre, estado, and version fields to ConxDb model and update Create/Update functions 2026-05-21 10:16:57 -05:00
Lizandro Guarnizo 240559e867 up 2026-05-01 11:58:18 -05:00
root fd739f8675 Descripción de los cambios 2025-04-24 02:07:47 +00:00
Felipe 462eb0d42c cruds update 2025-02-12 08:05:24 -05:00