Notifiche

Libre WebUI mantiene per ogni utente una casella di notifiche permanente, così le attività del team, come menzioni, messaggi diretti, condivisioni, errori delle automazioni e promemoria del calendario, raggiungono le persone anche quando la pagina interessata è chiusa.

Popup di stato

I brevi messaggi di stato, come una modifica salvata o un'operazione Git completata, compaiono vicino alla parte superiore della pagina. Usa il pulsante Chiudi per chiudere un popup con il puntatore o con la tastiera. Passando il puntatore sopra il messaggio, questo resta visibile così puoi leggerlo; chiuderlo elimina il messaggio, mentre l'operazione sottostante conserva il suo stato attuale.

Casella delle notifiche

Le notifiche sono innanzitutto righe del database: titolo e corpo sono crittografati quando vengono archiviati, il limite è di 500 per utente (le più vecchie vengono eliminate) e una chiave sorgente facoltativa consente di deduplicarle, così pubblicazioni ripetute confluiscono in un'unica voce anziché riempire la campana di avvisi. La superficie RESTful permette di elencarle, contare quelle non lette, segnarne una o tutte come lette ed eliminarle.

La distribuzione in tempo reale usa il flusso di eventi permanente per utente notify:<userId> tramite GET /api/notifications/events (SSE). L'identità del flusso deriva dalla sessione autenticata, mai dall'input del client, e la casella SQL resta la fonte autorevole: un evento perso viene recuperato leggendo l'elenco, non riproducendo il flusso.

Eventi che producono notifiche

Tipo	Quando viene prodotta
channel-dm	Qualcuno ti invia un messaggio diretto
channel-mention	Qualcuno ti @mentions in un canale o risponde al tuo messaggio
channel-invite	Vieni aggiunto a un canale
share	Qualcuno condivide una risorsa con te
automation-failed	Una delle tue automazioni non riesce, salvo che abbia disattivato l'opzione
calendar-reminder	Un evento con promemoria raggiunge l'orario previsto
work-run-finished	Uno degli agenti Work che hai incaricato completa un'esecuzione
work-run-attention	Un agente incaricato si ferma in attesa di input o incontra un errore
work-takeover	Un agente Work ti chiede di assumere il controllo del suo schermo
work-approval	Un'esecuzione Work attende che tu approvi un'azione con effetti collaterali
system	Annunci a livello di istanza

Le notifiche vengono sempre pubblicate soltanto per l'utente interessato; la menzione di un nome utente che non appartiene al canale non produce nulla.

Le notifiche possono anche attivare automazioni: un'automazione con un trigger event viene eseguita ogni volta che una notifica del tipo scelto raggiunge il suo proprietario, limitata da un periodo di attesa di un minuto per automazione.

Webhook in uscita

Gli amministratori possono registrare destinazioni webhook che ricevono gli eventi del team.

• Uscita protetta. Le destinazioni sono sottoposte agli stessi criteri dei server di strumenti: URL esatto, nessun reindirizzamento e nessun indirizzo privato o link-local, a meno che l'amministratore non inserisca esplicitamente un host in TOOLS_PRIVATE_NETWORK_ALLOWLIST. I nomi host vengono risolti e controllati nuovamente a ogni distribuzione.
• Firmati. Quando è configurato un segreto, ogni distribuzione include X-Libre-Signature: sha256=<hmac>, calcolato sul corpo esatto.
• Con dati rimossi. L'involucro contiene il tipo di evento e di notifica, il titolo, gli identificatori e i timestamp. Corpi delle notifiche, contenuti dei messaggi, prompt e documenti non lasciano mai l'istanza.
• Permanenti. Le distribuzioni vengono eseguite come processi permanenti con un numero limitato di tentativi; una risposta 5xx del destinatario viene ritentata, mentre una risposta 4xx è considerata il verdetto del destinatario e conclude il tentativo.
• Con ambito. Ogni destinazione si abbona a tipi di notifica specifici oppure a *.

Notifiche push del browser

Impostazioni → Notifiche registra questo browser per Web Push, così menzioni, condivisioni, promemoria e attività completate raggiungono il dispositivo anche quando la scheda è chiusa. L'implementazione è standard e autonoma:

• VAPID (RFC 8292). Il server firma ogni distribuzione con una coppia di chiavi ES256, generata una volta e archiviata in forma crittografata oppure fissata tramite VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY (VAPID_SUBJECT imposta il campo del contatto). Non sono coinvolti servizi o librerie push di terze parti, oltre all'endpoint push del fornitore del browser.
• Payload crittografati (RFC 8291). Ogni messaggio viene crittografato con aes128gcm per le chiavi specifiche del dispositivo prima di lasciare l'istanza; il servizio push inoltra testo cifrato che non può leggere.
• Per dispositivo e associati alla sessione. Un abbonamento appartiene al browser che lo ha creato e alla sua sessione di autenticazione: la disconnessione della sessione (o l'opzione «disconnetti le altre sessioni») rimuove anche la registrazione push. Gli endpoint vengono archiviati in forma crittografata con un token di ricerca con chiave e devono essere destinazioni HTTPS pubbliche, applicando le stesse precauzioni per il traffico in uscita dei webhook.
• Permanenti. Le distribuzioni push vengono eseguite come processi permanenti con un numero limitato di tentativi; se il servizio push segnala che l'abbonamento non esiste più (404/410), viene rimosso.
• Il payload contiene il titolo della notifica, il corpo facoltativo, il tipo e il link di destinazione, con la stessa politica di rimozione dei dati della casella.

Le notifiche push richiedono l'app di produzione (il service worker viene registrato soltanto in tale ambiente) e un'origine sicura. La shell offline e la possibilità di installazione provengono dallo stesso service worker: il manifesto dell'app rende Libre WebUI installabile, quando si è offline la navigazione passa alla shell memorizzata nella cache e le risorse di build con hash vengono memorizzate in modo immutabile. Il traffico API non viene mai memorizzato nella cache.

Email

L'email è il terzo canale di distribuzione, e l'unico che richiede una configurazione da parte di un amministratore. Impostazioni → Gestione utenti → Accesso e criteri → Notifiche email contiene un unico server SMTP in uscita: host, porta, sicurezza della connessione (STARTTLS, TLS implicito o nessuna per una rete affidabile), credenziali facoltative, l'indirizzo del mittente e l'URL pubblico usato per i link. Le variabili d'ambiente SMTP_* in Variabili d'ambiente inizializzano gli stessi campi per le distribuzioni in container; un valore salvato nella UI ha la precedenza. La password viene memorizzata cifrata e non viene mai restituita al browser. Invia prova consegna un messaggio all'indirizzo dell'amministratore stesso (o a un indirizzo digitato) così il percorso completo viene verificato prima che gli utenti vi facciano affidamento.

Gli amministratori scelgono anche un modello email Chiaro o Scuro e lo visualizzano in anteprima prima di salvare. Chiaro è il valore predefinito. Il preset salvato si applica a ogni notifica ed email di prova di questa istanza, compresi i risultati Markdown; è indipendente dal tema dell’interfaccia di ciascun utente. L’anteprima mostra contenuti di esempio senza contattare SMTP, inviare email o accodare un job. Solo gli amministratori possono leggere o modificare il preset o richiedere un’anteprima. I preset integrati mantengono leggibili testo, link, blocchi di codice e pulsanti; i modelli HTML personalizzati non sono accettati. I client email possono comunque regolare i colori secondo le proprie impostazioni di visualizzazione.

Una volta attivato l'interruttore, ogni utente sceglie cosa raggiunge la propria casella in Impostazioni → Notifiche → Notifiche email:

• Menzioni nei canali: un messaggio che ti menziona in un canale, con l'anteprima e un link al canale.
• Risultati delle automazioni: l'esito di ogni esecuzione delle tue automazioni, riuscita o fallita. Un'esecuzione di chat riporta la risposta stessa dell'assistente (fino a qualche migliaio di caratteri); un'esecuzione Work riporta la riga di stato dell'attività; un fallimento riporta l'errore. Il link apre la chat o l'attività risultante.

Entrambi gli interruttori restano disattivati finché l'utente non li attiva, e funzionano solo per gli account che hanno un indirizzo email, impostato dal titolare dell'account in fase di registrazione oppure aggiunto da un amministratore in Utenti. I messaggi partono attraverso lo stesso runtime di job permanente del Web Push, con tentativi limitati per gli errori transitori del relay, e il client SMTP è una piccola implementazione integrata (EHLO, STARTTLS, AUTH PLAIN o LOGIN) che non invia mai le credenziali su una connessione non cifrata a meno che la modalità non sia esplicitamente none. Ogni messaggio ha una parte in testo semplice e un'alternativa HTML nello stile del sito: il logo di Libre WebUI, un riquadro con il contenuto, un pulsante corallo verso la destinazione e un piè di pagina che rimanda a Impostazioni → Notifiche. Un risultato di automazione viene reso a partire da Markdown (titoli, elenchi, enfasi, codice, link solo verso destinazioni http(s)); tutto il resto viene sottoposto a escaping, e l'unica immagine esterna è il logo servito da librewebui.org. Nessun tracciamento.

Confini

• Le preferenze utente per tipo non sono ancora implementate; le automazioni rispettano la propria impostazione di notifica e l'uscita da un canale interrompe le relative notifiche.