Użytkownicy powinni mieć dostęp do wiadomości, które widzą po zalogowaniu się do systemu.
Powiadomienia dzielą się na następujące kategorie:
1. Powiadomienia wyświetlane przed zalogowaniem klienta do systemu
Pojawiają się pomiędzy nagłówkiem „Portal klienta” a polem wprowadzania e-maila.
Muszą być wizualnie wyróżnione — na przykład tłem (czerwonym lub żółtym) lub w inny sposób — projekt według własnego uznania.
Podawane są data i czas, w których powiadomienie jest wyświetlane.
Czas rozpoczęcia wyświetlania jest ustawiony domyślnie, ale może nie odpowiadać czasowi utworzenia powiadomienia.
Data i czas zakończenia domyślnie — następny dzień, 23:59.
Jeśli jest kilka powiadomień, łączą się w jeden blok, gdzie może być do 4–5 zdań; przy każdym powiadomieniu w mniejszej czcionce podane są data i czas rozpoczęcia jego obowiązywania.
Sortowanie — według daty rozpoczęcia (rosnąco).
2. Powiadomienia wyświetlane po zalogowaniu klienta do systemu (przed rozpoczęciem pracy)
Pojawiają się na stronie głównej (Panel / „Przegląd”) — pomiędzy nagłówkiem „Przegląd” a listą działań.
Możliwe są różne opcje zachowania:
Wyświetlane są przez ustalony okres (data i czas rozpoczęcia/zakończenia);
Lub wyświetlane są dopóki użytkownik nie naciśnie przycisku „Potwierdzam przeczytanie” — po tym powiadomienie nie jest już pokazywane temu użytkownikowi. Do momentu naciśnięcia przycisku przejście do innych sekcji portalu jest zabronione. W tym przypadku data zakończenia nie ma znaczenia.
Lub wyświetlane są z wymaganiem potwierdzenia, ale do daty zakończenia są pokazywane za każdym razem przy logowaniu, nawet jeśli użytkownik już nacisnął „Potwierdzam przeczytanie”. To jest odpowiednie, na przykład, dla przypomnień o zaległościach klienta.
Jeśli jest kilka powiadomień, również łączą się w jeden blok.
Przycisk „Potwierdzam przeczytanie” pojawia się raz dla całej grupy aktywnych powiadomień i tylko jeśli wśród nich jest przynajmniej jedno wymagające potwierdzenia.Powiadomienia mogą być:
dla wszystkich użytkowników,
dla użytkowników określonych klientów (wielokrotny wybór klientów),
tylko dla konkretnych ról (w tym przypadku klient nie ma znaczenia — powiadomienie jest pokazywane wszystkim z daną rolą).
3. Ogólne wymagania
We wszystkich powiadomieniach dopuszczalne jest formatowanie tekstu i użycie zewnętrznych/wewnętrznych linków.
Wszystkie powiadomienia i potwierdzenia muszą być wyświetlane bez okienek pop-up.
4. Administracja powiadomieniami
Dostępne w osobnej sekcji, na razie tylko dla roli „debug master” (w przyszłości możliwe utworzenie osobnej roli).
Możliwości: tworzenie, wyszukiwanie, filtrowanie, edytowanie i usuwanie powiadomień, analogicznie do już zrealizowanego filtrowania i wielokrotnego wyboru użytkowników itd.
Pola powiadomienia:
Data i czas utworzenia
Twórca (użytkownik)
Data i czas rozpoczęcia wyświetlania (domyślnie = czas utworzenia)
Data i czas zakończenia wyświetlania (może być null)
Obowiązkowość potwierdzenia przeczytania
Klienci, dla których jest wyświetlane (domyślnie — wszyscy)
Role, dla których jest wyświetlane (domyślnie — wszyscy)
Tekst wiadomości — formatowalny, minimum wsparcie pogrubienie / kursywa / podkreślenie, możliwość wstawienia URL.
5. W sekcji klienta
Dodawane są dwa linki:
do tworzenia powiadomienia, gdzie klient jest podstawiany domyślnie;
do listy powiadomień (w tym historia) — te, które były widoczne temu klientowi (tzn. filtr według clientId).
6. W sekcji użytkownika
Można zobaczyć, jakie powiadomienia temu użytkownikowi były pokazywane po raz pierwszy, kiedy i o której godzinie — te dane powinny odpowiadać czasowi logowania użytkownika do systemu (czas logowania).
Również na liście wyświetlane jest, kiedy użytkownik naciskał potwierdzenie przeczytania dla powiadomień, gdzie to jest wymagane.
To ogólny opis.
Czekamy na pytania i sugestie, jeśli uważasz, że coś powinno być zrealizowane inaczej.
Czy chcesz, żebym również przetłumaczył ten tekst na język angielski — aby można go było wykorzystać w specyfikacji technicznej lub wewnętrznej dokumentacji zespołu?
Ryga