What do we want to achieve?

The goal of this change is to reduce the amount of messages users are getting by default.

Desire is to change the default system behavior so that the ‘default’ for a user is to get fewer messages.

Approach #1 (Consolidated message)

Overview

This page describes the design for supporting notification consolidation for the notification service. It is an output of the .

Pros

• consolidation logic lays within notification service

• the feature can be fairly easy reused by other client services

• pretty straightforward when implementing simple, non-dynamic messages like

  There are 5 requisitions waiting for your approval, click below to approve them.
  https://test.openlmis.org/#!/requisitions/approvalList

Cons

• implementing more sophisticated(more dynamic) notifications, like below, will increase the complexity greatly by introducing message parameters and/or callbacks to the client service (most likely both)

  There are 5 requisitions waiting for your approval:

  
  

  Requisition at XYZ for XYZ program

  https://test.openlmis.org/#!/requisition/requisition-1-id/fullSupply

  
  

  Requisition at YZX for YZG program

  https://test.openlmis.org/#!/requisition/requisition-2-id/fullSupply

  
  

  Requisition at ZYX for ZYX program

  https://test.openlmis.org/#!/requisition/requisition-3-id/fullSupply

  
  

  Requisition at YXZ for YXZ program

  https://test.openlmis.org/#!/requisition/requisition-4-id/fullSupply

  
  

  Requisition at ZXY for ZXY program

  https://test.openlmis.org/#!/requisition/requisition-5-id/fullSupply

Class diagram

Tag

This new addition to the notification class would let us group notification together to be sent as a single, consolidated message later.

DigestConfiguration

Digest configuration will define how messages can be consolidated. The idea here is to let each of the services define possible ruling for the message digest. Each configuration will contain the following fields:

• Id - the UUID of the configuration.
• Time - time at which the digest should occur.
• Message - consolidated message to be sent instead of the individual ones. This would be a string accepting a single parameter (the number of sent notification) at the start, we could then think about a way of making this more configurable.
• Tag - which tag should be digested by this configuration.

DigestSubscription

This entity would let each of the user to decide whether or not they would like to use each of the digest configurations.

Activity diagram

Below is the activity diagram describing how notification would deal with digesting notifications and sending them daily. It is split into 4 workflows (from left to right):

1. Registering a digest configuration. This step is done by the service and provides possible notification consolidation options.
2. A user subscribing to a specific digest configuration. From this step, the user will no longer receive the notifications for a specific tag as they come but in a form of a single, digested notification.
3. Notification receiving a notification to send. This workflow deals with deciding whether to send the notification immediately or store it to be digested.
4. Notification coursing through the digest configuration and sending messages for all the subscribers when the time is appropriate.

Approach #2 (Consolidated Message Opt-out)

Overview

With this approach, we're not implementing message consolidation in a way that we decide to either receive the consolidated message or individual messages. It lets the user decide on a per message-type basis which of them they want to receive.

The main focus here is on adding the ability to opt out of specific message types individually. On top of that, we would add new message types (that would serve as the consolidated messages) would be added to each of the services (requisition being the first one).

Example:

We have 2 message types: REQUISITION_APPROVAL and REQUISITION_APPROVAL_SUMMARY.

The first one is the notification we currently have implemented that informs the recipient about a specific requisition being approved.

The second one is a new notification type that sends a notification daily informing the recipient how many requisitions have been approved.

With this approach, the user can decide to opt into one, both or none message types so they can receive information for each requisition individually, a daily summary, both or none.

Pros

• Less logic in the notification service
• Provides additional feature of opting out of notifications
• Notification is prepared by the client service so it can be as sophisticated as it needs to be without increasing complexity on the notification service side

Cons

• Logic responsible for scheduling the message have to reside inside the client service
  • When should we send the message? The client needs to know when to send the message so it can include all the data needed
• Possible duplications between multiple client services (scheduling logic mostly)

Class diagram

NotificationType

Class describing a single notification type. It is registered by each of the client services on startup.

• ID - the ID of the notification type
• name - the name of the notification type, send together with the notification
• optOutByDefault - flag defining whether new users should be opted out of this notification type by default

Notification

Notification is extended with a single field called notification type, it is used by the notification service to define whether the message should be sent or not.

UserContactDetails

This class is extended by the list of notification that the related user want to be opted out.

Activity diagram