Zadanie #1638
Zadanie #1637: Notyfikacje systemowe
Utworzenie serwisu do zapisywania notyfikacji
| Status: | Rozwiązany | Start date: | 2017-05-11 | |
|---|---|---|---|---|
| Priority: | Normalny | Due date: | 2017-05-11 | |
| Assignee: | Michał Komar | % Done: | 100% | |
| Category: | backend | |||
| Target version: | 0.3 | |||
| Developer: | Michał Komar | Tester: | Łukasz Waśkiewicz |
Description
Serwis powinien pozwalać na zapiwywanie oraz odczyt notyfikacji. Ponadto, podczas zapisywania notyfikacji, powinien zostać wysłany event, który spowoduje wysłanie wiadomości poprzez websocket do wszystkich zainteresowanych.
Należy umożliwić zdefiniowanie 2 typów adresatów: konkretny użytkownik oraz rola.
W przypadku roli trzeba też dookreślić grupę użytkowników oraz, czy informacja ma się propagować w górę (np. czy wysyłać do administratora, gdy adresatem jest redaktor).
Dodatkowo należy zaimplementować oznaczanie notyfikacji jako przeczytana + usuwanie per użytkownik.
Serwis powinien integrować się z serwisem wiadomości. Weryfikacja, czy adresat wiadomości jest dobry, powinna się odbywać poprzez filtry definiowane podczas rejestracji odbiorcy wiadomości (rejestracja ma miejsce podczas otwarcia websocketa).
Related issues
Associated revisions
refs #1638: Dodanie serwisu w wersji #1
refs #1638: Dodanie modelu w jpa + sql
refs #1638: Dodanie modelu w jpa + sql - kolejny etap
refs #1638: Dodanie wyszukiwania duplikatów i doklejanie źródeł
Zmiana modelu -> jedna notyfikacja może mieć wiele źródeł, w ten sposób
nie duplikujemy notyfikacji
refs #1638: Persystowanie notyfikacji. Obsługa wielu źródeł
refs #1638: Dodanie dezaktualizacji confirmation required po confirmed
refs #1638: Dodanie kontrolera
refs #1638: Poprawienie konwersji
refs #1638: Poprawienie konwersji
refs #1638: Poprawienie sqli w h2
refs #1638: Dodanie animowanej ikonki z powiadomieniami
refs #1638: Dodanie listy i szczegółów notyfikacji. j-autosize - moved
refs #1638: Zmiana logiki weyfikacji ilości notyfikacji. Tłumaczenie
refs #1638: Tłumaczenia. Poprawki.
refs #1638: Dodanie obsługi publishing notification
refs #1638: Dodanie obsługi wszystkich rodzajów notyfikacji.
Ponadto poprawienie RWD dla filtrów w tabelach. Poprawienie błędnej
obsługi Operation.
History
#1 Updated by Michał Komar about 7 years ago
- Description updated (diff)
#2 Updated by Michał Komar about 7 years ago
- Assignee set to Michał Komar
#3 Updated by Michał Komar almost 7 years ago
- Description updated (diff)
- Assignee changed from Michał Komar to Jarosław Bąbel
- Developer Jarosław Bąbel added
- Tester Michał Komar added
#4 Updated by Michał Komar almost 7 years ago
- Follows Zadanie #1708: Rejestracja użytkowników jako odbiorców wiadomości added
#5 Updated by Michał Komar almost 7 years ago
- Assignee changed from Jarosław Bąbel to Michał Komar
- Developer Michał Komar added
- Tester Łukasz Waśkiewicz added
#6 Updated by Michał Komar almost 7 years ago
- Assignee changed from Michał Komar to Wojtek Hury
- Developer Wojtek Hury added
#7 Updated by Wojtek Hury over 6 years ago
- Assignee changed from Wojtek Hury to Michał Komar
- Developer Michał Komar added
#8 Updated by Michał Komar over 6 years ago
- Status changed from Nowy to Rozwiązany
- Assignee changed from Michał Komar to Łukasz Waśkiewicz
- % Done changed from 0 to 100
W międzyczasie zmieniła się koncepcja.
Notyfikacje przeznaczone są tylko dla konkretnych użytkowników (nie dla ról). Podczas dodawania notyfikacji trzeba określić kogo ona dotyczy. Za określanie adresatów odpowiedzialna jest klasa DocumentNotificationsProducer - w ramach testów można zweryfikować, czy działa poprawnie.
Nie dorabiałem testów integracyjnych i jednostkowych do tego serwisu.
Flow przetwarzania wygląda następująco:
1. Producer obsługuje event aplikacji i w tworzy na jego podstawie notyfikacje (może powstać wiele notyfikacji w wyniku jednego eventu). W ramach eventu wszystkie wygenerowane notyfikacje mają jednego, takiego samego sourceUsera. Notyfikacja jest generowana per target user.
2. Wygenerowane notyfikacje przekazywane są do notificationservice. Tam sprawdzane jest, czy notyfikacja nie jest duplikatem (taki sam targetUser, żródło notyfikacji - dokument, proces; typ notyfikacji oraz flagi read=false i valid = true). Jeżeli nie jest duplikatem dodawana jest nowa notyfikacja, jeżeli jest, dodawany jest sourceuser do istniejącej notyfikacji. Notyfikacja następnie jest wysyłana poprzez websocket do targetUsera. Notyfikacja jest wysyłana tylko w momencie, gdy została zmodyfikowana (jeżeli sourceUser na duplikacie istnieje, wtedy nie ma zmiany)
3. Na koniec weryfikowane jest to czy obecna notyfikacja nie ma wpływu na istniejące. W tym momencie jeżeli przychodzi notyfikacja CONFIRMED, wszystkie notyfikacje CONFIRMATION_REQUIRED mają ustawianą flagę valid na false.
#9 Updated by Michał Komar over 6 years ago
- Status changed from Rozwiązany to Testowanie
#10 Updated by Łukasz Waśkiewicz over 6 years ago
- Status changed from Testowanie to Odpowiedź
- Assignee changed from Łukasz Waśkiewicz to Michał Komar
notyfikacja Potwierdzono nie przestaje być aktualna jeśli inny użytkownik opublikuje zmiany
#11 Updated by Michał Komar over 6 years ago
- Status changed from Odpowiedź to Rozwiązany
Przedyskutujemy kwestie zachowania notyfikacji na spotkaniu.