Logica di Notifica: Input & Permessi

Il microservizio Notification gestisce l'invio multicanale reagendo agli eventi generati dal sistema.

1. Il Flusso "Trigger"

1. Analisi a Monte (Events Service)

   • Il servizio Events analizza costantemente il flusso GPS.
   • Se rileva un problema (es. Overspeed > 130km/h), crea un oggetto evento.
   • SCRITTURA: Scrive l'evento sullo stream Redis events (XADD).

2. Ricezione Immediata (Notification Service)

   • Il servizio Notification ascolta lo stream events (Consumer Group notification-consumers).
   • LETTURA: Appena appare un messaggio, si attiva (_process_event).

3. Verifica Permessi e Invio

   • Il servizio controlla le impostazioni specifiche del dispositivo (DeviceNotificationSettings).
   • Se un canale (Email, Push, Call) è disabilitato per quel dispositivo, l'invio viene saltato.
   • Se abilitato, procede all'invio tramite il provider esterno (Firebase, SMTP, Bland AI).

2. Gerarchia delle Impostazioni

Il sistema applica una logica "a imbuto" per decidere se inviare:

1. Accesso Dispositivo: L'utente ha accesso a questo dispositivo? (Tabella user_device_permissions)
2. Impostazioni Utente Globali: L'utente ha abilitato le notifiche in generale? (NotificationSettings)
3. Impostazioni Dispositivo Specifiche: L'utente ha silenziato questo dispositivo specifico per questo canale? (DeviceNotificationSettings - FIXED)
   • Email: Controlla email_enabled
   • Push: Controlla push_enabled
   • Call: Controlla call_enabled

3. Perchè Redis?

Usare Redis qui è fondamentale per la velocità:

• Meccanismo Push: l'evento arriva in millisecondi.
• Disaccoppiamento totale tra chi genera l'allarme (Events) e chi lo spedisce (Notification).