RFC: Alert /Notification Management Framework & UI Interface to control Notifications

[parthlawate]

A. Extend Notification system to allow additional Adapters for send methods
Sunbird ED sends a variety of notifications today. We need an easy way to extend this to allow support for multiple notification channels like :

1. Emails
2. Web Push
3. SMS
4. Native
5. Webhook (to allow other integrations like Slack etc)
6. WhatsApp etc

B. Template Management System for Tenant Admins
Notification content with replacement tags should be editable via an Admin UI frontend & we should be able to configure the content , and allow multilingual notification content & override content on a tenant level

C. User control on Notifications
Allow users to control what notifications they receive and via what channels

Reference opensource product built on PHP which does this https://github.com/techjoomla/TJ-Notifications (this is a product built and opensourced by Tekdi & used in some 8-10 other Building block products & several projects

[Krishnaj20]

thanks @parthlawate for starting this thread. Would you like to contribute these capabilities to Sunbird Lern? We can take this thread forward accordingly.

@vinukumar-vs @rhwarrier @reshmi-nair

[parthlawate]

This would be part of our efforts to ease the management of Sunbird Tenants. So this would eventually need to be part of the 'Admin Portal'. We would want to take this up but before that would love inputs from the community & DC on these so we can see if there is a wider requirement for this. .

[Krishnaj20]

thanks @parthlawate . I believe self serviceability of notifications both for admins and end consumers will be a useful capability, and enabling notifications thru multiple end points will also be needed as diverse customers start using ED.

@SunbirdED_WorkingGroup - Pls do share your inputs about this new RFC.

@rhwarrier @luckynvdu @kiranharidas187 @vrayulu @SanthoshVasabhaktula @rajeevsathish @swayangjit
@sharathkashyap @aishwaryashikshalokam @Prateek-slokam @aks30 @varsha-sl @MeghnaSL @reshmi-nair @vinukumar-vs

[SanthoshVasabhaktula]

@parthlawate @Krishnaj20 - Isn't UCI specifically built for these admin capabilities? Can we check it and see how we can integrate with it?

User controlling the alerts/notifications that they can receive should be designed as part of profile configuration. Transactional alerts are always sent (like OTP, certificate received etc), but for all non transactional alerts User should have an option to switch off notifications, but they would still be visible within the in-app notification window.

[parthlawate]

Not sure @rahul101001000 @ChakshuGautam can you jump in ?

[rahul101001000]

tldr: UCI does not include notification management on client side. More details below -

There are four parts to a full notification experience using UCI -

1. Single API for multi channel (SMS, Whatsapp, Telegram, IVRS, ...) communication and backend adapters for channel providers (e.g. NIC SMS gateway, Gupshup, etc)
2. Transformers for logic and enhancements to messages flowing through pipes in 1 above (e.g. translation from language A to B, generation pdf resume from previous chat responses, routing responses, etc)
3. Admin interface to configure 1, 2 for a tenant
4. Client notification settings (on the receiver side)

UCI does 1, 2; DIKSHA implementation of UCI does 3; 4 is not part of UCI but an implementation/plan may exist for Shiksha.

--
On the RFC bit, agree with @SanthoshVasabhaktula that the notification settings should be part of profile configuration in frontends that they use. In addition to switching on or off, consider the sender labeling notification with a type, users can choose to subscribe to some types while unsubscribe from others. Also when thinking about the client side experience for notifications, consider different formats for displaying notifications (with/without image/media), inline actions, coalescing notifications.

--
Hope this helps.