Context

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 as pushToCustomerChannel does, but the channel 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:

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)