Context
Requirements: https://safibank.atlassian.net/wiki/spaces/ITArch/pages/190776618/Backoffice+notifications#BOFE-web-notifications
The mobile app is already using PUSH notifications delivered Via Ably and Service: push-notifications-gateway and the goal are to reuse that infrastructure as much as possible.
Sending notifications (BE)
In Service: push-notifications-gateway there is a listener that listens to push notification commands (from the output manager) and then calls
pushNotificationsService.pushToCustomerChannel( UUID.fromString(vendorMessage.idempotencyId.toString()), vendorMessage.toAblyJson(), UUID.fromString(vendorMessage.customerId.toString()) )
When sending notifications for BOFE we’ll circumvent the output-manager
and will use the push-notification-gateway
directly
We created a new topic for bank user notifications
commons.send_bank_user_push_notifications.command.v1
We created the
pushToBankUserChannel( ..., ..., vendorMessage.bankUserId)
that will send the notification in the same way aspushToCustomerChannel
does, but thechannel
would be"bankUser:$bankUserId"
This means that for each bank user there will be a separate notifications channel (as with customer notifications).
The actual sending of notifications is done by publishing Kafka commands in moments defined by the requirements above.
Notifications texts
Title | Message
Checker notifications:
Change for review | A change related to task {task ID} is awaiting your review.
Maker notifications:
Change approved | Your change related to task {task ID} has been approved.
Change rejected | Your change related to task {task ID} has been rejected.
Change rejected | Your change related to task {task ID} has been automatically rejected at the end of the day.
Change failed | Your change related to task {task ID} has been approved but failed to be applied.
Other related information like who rejected it, or what the change is will be available in BOFE and does not have to be in the notification message itself.
Receiving notifications (FE)
We use Ably’s js APIs directly, as it’s enough to have a notifications bell in the webapp.
The BOFE will connect to a notifications channel
Channel name:
"bankUser:{userId}"
Schema of the message SendBankUserPushNotificationCommandV1.avsc
The number of unread messages will show in the bell icon
User also has the option to see all notifications on a separate page
Also, see designs https://www.figma.com/file/eyJ3AMGVxHZYTxNLXxTH2D/SaFi---Back-Office-UI?node-id=1717%3A41488&t=UvH9As4GUXgrQYe8-0
Current status after handover:
POC made https://github.com/SafiBank/SaFiMono/pull/8249
Allows live collection of notifications
Listing notification history and resetting notification status (BE)
Since ably can not store notifications, so when we push the notification to ably, we store it in our DB also.
There is the pr includes endpoints about listing notification history and resetting notification status from unread to read or another status. SM-8031 - Getting issue details... STATUS
Listing notification history: /notifications, this endpoint supports paging, which you can see here: /notifications
Resetting notification status: the notification default status is ‘UNREAD', and all the notification from Ably is 'UNREAD’, you can use the endpoint /notifications/resetStatus, this endpoint supports batch status modification, which can be detailed here: /notifications/resetStatus
enum class NotificationStatus { UNREAD, // the notification is not read yet READ, // the notification has been read OUT_DATED, // the notification is out of date as it's created long time ago but never read DELETED, // the notification is soft-deleted either by bofe admin or user themselves. }
Ably access
Ably dashboard: https://ably.com/login (Make sure to use Login by SSO, access is given via Okta)