Enable generic way of sending notifications - these notifications should be capable of being delivered via the Community App, via the Android app for field officers or Android self-service app.
To allow the user to directly act upon the alert directly from the notification (i.e. approve a client). This is what actionable means.
Approach for designing a generic notification system
The designing of the notification system will be done in two parts :-
Notification generation and storage
Notification Generation and Storage
This part contains information about how notifications are being generated in the backend and what design they follow for their generation.
There is an event (like new Loan Request by Loan Officer) which is broadcasted.
The event listener gets the message (that a new Loan Request was made)
Note :- This part (broadcasting and receiving a message) has to be asynchronous and it can be achieved by implementing message queues. Read about message queues here. We have used ApacheActiveMq for implementing this behaviour.
The listener will now do something - for example :- Generate the notification and save it in the database by mapping it to the user for whom it was generated .
Each generated notification will contain the following attributes :
Subject --> Object --> Action --> Actor
Subject - The user who needs to be notified Object - The object on which action happened Action - The action that resulted in this notification Actor - Who did it
All the notifications can fit into this model. Now for our standard branch manager - loan officer interaction the notification may look like
Notify [User 322] a [new loan application] was [created] by [User 432]
subject object action actor
This part contains information about how notifications are being stored in the database after their generation and what data model design they follow.
Two tables are being used for storing the generated notifications.
1. notification_generator:- This table contains the attributes of the generated notification.
id :- The id of the generated notification.
object_type :- The type of object for the generated notification.
object_identifier :- The id of the object by which it is identified in the database.
action :- Type of action performed by the actor. The actions may be created, updated, deleted etc.
actor :- Username of the actor which acts upon the action.
is_system_generated :- It is a boolean value. This column tells whether the notification was generated by the system or by the user.
notification_content :- This column contains the text of the generated notification which would be shown to the user for whom it was generated. For e.g A new client with name ABC was created by mifos.
created_at :- It contains the date and time of the generated notification.
2.notification_mapper :- The table maps the id of generated notification with the id of a user for whom it was generated.
id :- The id of mapped notification.
notification_id :- It contains the id of a notification which has to be mapped to a user. This is coming from the notification_generator table.
user_id :- It contains the id of a user for whom the notification is mapped.
is_read :- It is a boolean value. It tells whether the notification has been read by the user or not.
created_at :- It contains the date and time of the mapped notification.
For each REST request which the UI makes the server will send back a response header for e.g 'X-Notification-Refresh' with each response containing the value of either true or false depending upon whether new notifications are present on the server or not.
If no REST request has been made for certain time interval then a new REST request is made to check whether there are new notifications on the server or not.