Powiadomienia

Libre WebUI utrzymuje trwałą skrzynkę dla każdego użytkownika, dzięki czemu aktywność zespołu — wzmianki, wiadomości bezpośrednie, udostępnienia, błędy automatyzacji i przypomnienia kalendarza — dociera do ludzi nawet po zamknięciu strony.

Wyskakujące komunikaty o stanie

Krótkie komunikaty o stanie, na przykład o zapisanej zmianie lub zakończonej operacji Git, pojawiają się u góry strony. Przycisk Zamknij usuwa komunikat, zarówno wskaźnikiem, jak i z klawiatury. Najechanie kursorem sprawia, że komunikat pozostaje widoczny, więc możesz go spokojnie przeczytać; zamknięcie usuwa komunikat, a powiązana operacja zachowuje swój bieżący stan.

Skrzynka

Powiadomienia są przede wszystkim wierszami bazy: tytuł i treść są szyfrowane w spoczynku, limit wynosi 500 na użytkownika (najstarsze są usuwane), a opcjonalny klucz źródła deduplikuje powtórne publikacje w jedną pozycję. Powierzchnia RESTful wyświetla, liczy nieprzeczytane, oznacza jedno lub wszystkie jako przeczytane i usuwa.

Dostarczanie na żywo korzysta z trwałego strumienia per użytkownik notify:<userId> przez GET /api/notifications/events (SSE). Tożsamość pochodzi z uwierzytelnionej sesji, nigdy z wejścia klienta, a skrzynka SQL pozostaje źródłem prawdy: pominięte zdarzenie odzyskuje się z listy, nie przez odtwarzanie strumienia.

Co tworzy powiadomienia

Typ	Kiedy powstaje
channel-dm	Ktoś wysyła wiadomość bezpośrednią
channel-mention	Ktoś @mentions Cię w kanale lub odpowiada na Twoją wiadomość
channel-invite	Zostajesz dodany do kanału
share	Ktoś udostępnia Ci zasób
automation-failed	Twoja automatyzacja kończy się błędem, chyba że wyłączyła powiadamianie
calendar-reminder	Zdarzenie osiąga czas przypomnienia
work-run-finished	Wynajęty agent Work kończy uruchomienie
work-run-attention	Agent zatrzymuje się po dane lub napotyka błąd
work-takeover	Agent Work prosi o przejęcie ekranu
work-approval	Uruchomienie Work czeka na zatwierdzenie działania ze skutkami ubocznymi
system	Ogłoszenia na poziomie instancji

Powiadomienie jest zawsze publikowane tylko do zainteresowanego użytkownika; wzmianka osoby spoza kanału nie tworzy niczego.

Powiadomienia mogą też uruchamiać automatyzacje: automatyzacja z wyzwalaczem event uruchamia się za każdym razem, gdy do jej właściciela dociera powiadomienie wybranego typu, ograniczona jednominutowym czasem odnowienia na automatyzację.

Wychodzące webhooki

Administratorzy mogą rejestrować cele webhooków odbierające zdarzenia zespołowe.

• Chroniony ruch wychodzący. Cele podlegają tej samej polityce co serwery narzędzi: dokładny URL, brak przekierowań i adresów prywatnych/link-local, chyba że administrator jawnie dopuści host przez TOOLS_PRIVATE_NETWORK_ALLOWLIST. Nazwy są ponownie rozwiązywane i sprawdzane przy każdej dostawie.
• Podpisane. Przy skonfigurowanym sekrecie każda dostawa ma X-Libre-Signature: sha256=<hmac> obliczony z dokładnej treści.
• Zredagowane. Obwiednia zawiera rodzaj zdarzenia, typ powiadomienia, tytuł, identyfikatory i znaczniki czasu. Treść powiadomień, wiadomości, prompty i dokumenty nigdy nie opuszczają instancji.
• Trwałe. Dostawy działają jako trwałe zadania z ograniczonymi próbami; 5xx jest ponawiany, a 4xx traktowany jako werdykt odbiorcy.
• Ograniczone zakresem. Cel subskrybuje konkretne typy lub *.

Powiadomienia push przeglądarki

Ustawienia → Powiadomienia rejestruje przeglądarkę w Web Push, aby wzmianki, udostępnienia, przypomnienia i zakończona praca dotarły także przy zamkniętej karcie. Implementacja jest standardowa i samodzielna:

• VAPID (RFC 8292). Serwer podpisuje dostawy parą kluczy ES256 wygenerowaną raz i zaszyfrowaną albo ustawioną przez VAPID_PUBLIC_KEY/VAPID_PRIVATE_KEY (VAPID_SUBJECT ustawia kontakt). Poza punktem push dostawcy przeglądarki nie uczestniczy zewnętrzna biblioteka ani konto usługi.
• Szyfrowane ładunki (RFC 8291). Każda wiadomość jest szyfrowana aes128gcm dla kluczy urządzenia przed opuszczeniem instancji; usługa przekazuje nieczytelny szyfrogram.
• Per urządzenie i sesję. Subskrypcja należy do przeglądarki i jej sesji uwierzytelniania; wylogowanie (lub „wyloguj inne sesje”) usuwa rejestrację push. Punkty są szyfrowane z kluczem wyszukiwania i muszą być publicznymi celami HTTPS, z taką samą ochroną ruchu jak webhooki.
• Trwałe. Dostawy push są trwałymi zadaniami z ograniczonymi próbami; odpowiedź 404/410 usuwa wygasłą subskrypcję.
• Ładunek zawiera tytuł, opcjonalną treść, typ i link docelowy — z taką samą redakcją jak skrzynka.

Push wymaga aplikacji produkcyjnej (service worker rejestruje się tylko tam) i bezpiecznego pochodzenia. Powłoka offline i instalowalność pochodzą z tego samego workera: manifest umożliwia instalację, nawigacja offline używa buforowanej powłoki, a zasoby z hashem są buforowane niezmiennie. Ruch API nigdy nie trafia do pamięci podręcznej.

E-mail

E-mail to trzeci kanał dostarczania i jedyny, który wymaga konfiguracji przez administratora. Settings → User Management → Access & policies → Email notifications przechowuje jeden wychodzący serwer SMTP: host, port, zabezpieczenie połączenia (STARTTLS, TLS od razu albo brak dla zaufanej sieci), opcjonalne dane logowania, adres nadawcy i publiczny URL używany do linków. Zmienne środowiskowe SMTP_* opisane w Zmiennych środowiskowych zasiewają te same pola przy wdrożeniach kontenerowych; wartość zapisana w interfejsie ma pierwszeństwo. Hasło jest przechowywane zaszyfrowane i nigdy nie wraca do przeglądarki. Wyślij test dostarcza wiadomość na adres administratora (albo dowolny wpisany adres), aby sprawdzić cały łańcuch, zanim użytkownicy zaczną na niego liczyć.

Administratorzy wybierają też szablon e-mail Jasny lub Ciemny i oglądają jego podgląd przed zapisaniem. Domyślny jest Jasny. Zapisane ustawienie dotyczy każdego powiadomienia i testowego e-maila w tej instancji, także wyników w Markdown; nie zależy od motywu interfejsu poszczególnych użytkowników. Podgląd renderuje przykładową treść bez łączenia się z SMTP, wysyłania poczty ani kolejkowania zadania. Tylko administratorzy mogą odczytać lub zmienić ustawienie albo poprosić o podgląd. Wbudowane ustawienia zachowują czytelność tekstu, linków, bloków kodu i przycisków; własne szablony HTML nie są akceptowane. Klienty poczty mogą mimo to dostosować kolory do własnych ustawień wyświetlania.

Gdy przełącznik jest włączony, każdy użytkownik wybiera, co trafia do jego skrzynki w Settings → Notifications → Email notifications:

• Wzmianki w kanałach: wiadomość, która wspomina Cię w kanale, z podglądem i linkiem do kanału.
• Wyniki automatyzacji: wynik każdego uruchomienia Twojej automatyzacji, udanego lub nie. Uruchomienie czatu niesie samą odpowiedź asystenta (do kilku tysięcy znaków); uruchomienie Work niesie wiersz statusu zadania; a niepowodzenie niesie treść błędu. Link otwiera docelowy czat lub zadanie.

Oba przełączniki są domyślnie wyłączone, dopóki użytkownik ich nie włączy, i działają tylko dla kont z adresem e-mail, który właściciel konta ustawia przy rejestracji albo administrator dodaje w sekcji Users. Wiadomości wychodzą przez to samo trwałe środowisko zadań co Web Push, z ograniczoną liczbą prób przy przejściowych awariach przekaźnika, a klient SMTP to niewielka wbudowana implementacja (EHLO, STARTTLS, AUTH PLAIN lub LOGIN), która nigdy nie wysyła danych logowania przez nieszyfrowane połączenie, chyba że tryb jest jawnie ustawiony na none. Każda wiadomość ma część tekstową i alternatywę HTML w stylistyce strony: wordmark Libre WebUI, jedna karta z treścią, koralowy przycisk prowadzący do celu i stopka odsyłająca do Settings → Notifications. Wynik automatyzacji jest renderowany z Markdown (nagłówki, listy, wyróżnienia, kod, linki tylko do celów http(s)); wszystko inne jest escapowane, a jedynym zewnętrznym obrazem jest logo serwowane z librewebui.org. Brak śledzenia.

Granice

• Preferencje użytkownika per typ nie są jeszcze dostępne; automatyzacje respektują własne ustawienie, a opuszczenie kanału zatrzymuje jego powiadomienia.