Avisos por correo configurables por usuario, paso A: preferencias y dirección confirmada (v1.170.0)

Valor para el usuario

Cada usuario puede elegir qué avisos de equipos quiere recibir por correo, si quiere recordatorios mientras el problema siga abierto y si quiere un aviso cuando se resuelva. Puede usar el correo de su cuenta o indicar otra dirección; esa otra dirección no recibe nada hasta que su dueño confirma pulsando un enlace.

Dónde está (v1.171.1): en CONFIGURATION > Users > User Settings, columna izquierda, sección “Email alerts” con su botón “Save Email Alerts”. Esa ventana la abre cualquier usuario (antes solo se abría desde “Users Management”, visible solo para admins, así que un técnico sin rol de admin no podía activar sus avisos). La ficha “Edit User” conserva la sección para que un admin configure los avisos de otra persona.

Límite del paso A (v1.170.0): este paso solo guarda preferencias y confirma la dirección. Todavía NO envía avisos de equipos; eso es el paso B, que deberá usar únicamente delivery_email().

Cómo se usa

1. El usuario abre User Settings (o, un admin, la ficha del otro usuario) y activa los avisos, elige tipos (device_down, device_flapping, cns_high, cns_any, sla_breach), repetición (once, 1h, 4h, 24h) y si quiere aviso al resolverse.
2. Si escribe una dirección distinta a la de la cuenta, recibe un correo de confirmación (48 h de validez, reenvío cada 10 min como mínimo).
3. Al abrir el enlace (/alerts/confirm/<token>) se muestra un botón; solo el POST de ese botón confirma. Así los antivirus de correo, que abren los enlaces solos, no confirman una dirección sin que nadie lo acepte.

Implementación

• Modelo UserAlertPreference (monitoring/models_alert_pref.py), uno por usuario y organización, con migraciones 0038 (tabla) y 0039 (RLS).
• delivery_email() devuelve la dirección de la cuenta siempre, u otra distinta solo si está confirmada; si no, None.
• El token viaja solo en el correo; en base de datos se guarda su hash sha256 y se borra tras el primer uso.
• La vista de confirmación busca por hash saliendo del RLS a propósito (rls_bypass), porque quien abre el enlace puede no tener sesión o tener la de otro tenant.
• Servicio monitoring/services/alert_confirmation.py: envío por Resend; si falta RESEND_API_KEY o falla el envío, devuelve False sin lanzar.
• API en monitoring/api/alert_prefs.py (GET y PUT).
• Front en static/js/alert_prefs.js: desde v1.171.1 pinta la misma sección en dos sitios con ids propios (my-alert-* en User Settings, alert-* en Edit User); window.CURRENT_USER_ID se define en templates/base.html y saveMyAlertPrefs está en la lista de acciones permitidas de static/js/base.js.
• CI: las plantillas de correo quedan fuera de la comprobación de tokens de diseño, porque los clientes de correo no entienden var(--).
• Límite v1.171.1: sin comprobar en pantalla según su propio CHANGELOG.

Commits relacionados

• 89e6197 (2026-09-29, PR #641, v1.170.0).
• 39af665 (2026-09-30, PR #644, v1.171.1): sección en la raíz de User Settings, abierta a todos.

Página parcial: describe el paso A y su ubicación en la interfaz. Actualizar cuando llegue el paso B (envío real de avisos).

Véase también

• [[feature—monitoring—notification-channel-encryption]]
• [[feature—monitoring—itsm-ciclo-cierre]]
• [[feature—monitoring—equipos-fuera-de-servicio]]
• [[feature—monitoring—sentinel-episodio-unico]]
• [[feature—monitoring—out-of-service-devices]]