| Page Properties | ||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
- Consolidated notifications
- Customizable rules for consolidation
- SMS and email notification supportAdd SMS as a notification channel
- Configurable to use SMS or email
- Administrator customization of notification messages
- Notification messages support tokens
- Customization of notification text for SMS and email
- View history of sent notifications, maybe as an adhoc report (this is a future goal - what is the value of this?)
...
- Different countries have different protocols and customs on how they notify individuals for different message types and what to say.
- Email notifications are supported for Requisition, Stock Management, Fulfillment, and User Password management.
- Other related meeting notes: Meeting Notes: OpenLMIS Notification requirements, See "What are the needs" section of User management - Opting out
- Emergency requisitions and reset passwords are types of notifications that override user settings to opt-out. These notifications are always sent.
- The Who below is defined using User Personas.
Requirement #1: Consolidated (Meaningful?) notificationsConsolidated Notifications (Notifications Daily Digest)
- Enable consolidation of notification messages so the user doesn't receive multiple unwanted notifications
...
- Configuring which notifications can be consolidated
- Configuring time that notifications will be sent (once daily)
- Enable selection of which channel to use to send a notification (SMS or email)
- For the first iteration, is it acceptable to have a default configuration for each notification class (listed in Open Question 7 below), and then allow for configurability in a future phase?
- Resend notifications (future release?)
- Timebound notifications (future release?)
- Disable notifications for unused services (example: Malawi has stock management but does not use it and could potentially receive stock management notifications that are not used)
- Is this really needed? Can this be customized by roles?
...
- Ability to configure and change the text used on email or SMS notifications template.
- Research using RapidPro or another existing service (Team Ona uses RapidPro)
- Support a more digest-like notification rather than a facility-specific notification (as shown in the example below
- Must be able to put values from the database (support tokens) when editing text
Background:
- Notification message text was drafted in consultation with program managers
- The system is connected to a third party SMS gateway or Email system
- Status in eLMIS: Implemented.
- Status in OpenLMIS: Partially Implemented. Implementers can change by editing the strings in each service. Values can come from the database.
Priority: High priority for Tanzania, Zanzibar, Zambia
- Must be able to put values from the database (support tokens) when editing text
Adam the administrator: the administrator or implementer that needs to customize the text to be used for different types of notifications
...
| # | Question | Outcome | Status | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 1 | Is
| SMS needs to be included in the feature set. Multiple countries mentioned that cost is not a concern as phone companies provide messages for free. | Answered | ||||||||||
| 2 | If SMS is no longer required - are there any requirements in Notifications - Push Reminders that we will need to support? Push notifications from an admin to all users happen through JIRA. Is this enough? | Only user stories 1 and 2 are required for the initial version. | Answered | ||||||||||
| 3 | Phone numbers are already captured in User Profile page - but there is only minimal validation on format. Is this required? It would be required if SMS is included in this feature. | Phone number format validation needs to be updated. | Answered | ||||||||||
| 4 | Need to research solutions for customizing messages in other languages | Messages need to be configurable but not localized | Answered | ||||||||||
| 5 | Who is the user that logs in occasionally? Do they need to receive notifications to remind them to log in and check something? | Understanding this user will help us ensure we support notification scenarios for this user. | Wesley Brown to confirm | ||||||||||
| 6 | Are there more types of notifications that could be categorized as high level? | Helps us understand which notifications would override a user's opt-out preferences. | Wesley Brown to confirm (maybe with help from Nikodem Graczewski (Unlicensed) to understand current state - emergency requisitions, reset password, are there others?) | ||||||||||
| 7 | Should we classify types of notifications so that we all agree on terms to use? Informative notifications: Requisition status updates (would notifications about upcoming system updates, planned system outages be included in this classification?) Action-based (action-oriented) notifications: Notifications that require the user to log into OpenLMIS to take action, some action-based notifications would override the user's notification preferences such as emergency requisitions or reset password email notifications. Time-bound notifications (or reminder notifications?): Notifications that remind a user something needs to be done, or hasn't been done yet - should be done Are there default settings for each notification class that would be acceptable?
What classifications should be used for notifications of system updates or planned system outages? This is a message that is configured by an administrator and then set to all users. (Malawi example, or is slack good enough?). | Gain agreement on terminology so we understand what notifications are supported and must be supported. Helps explain the value and use for each type. | Sam Im (Deactivated): This is a design discussion. This does not mean that notifications must be designed with a classification but is used to help us understand the value of notifications for each user. FYI Wesley Brown As of Dec 18th, and discussed in PC Meeting on Dec 18th: Two types of notifications will be supported in 3.6: Urgent and non-urgent Urgent: Emergency requisitions, password reset
Non-urgent: all other notifications Other classifications may be discussed for a future release | ||||||||||
| 8 | What are other generalized needs for requisitions and stock management (future design) | ||||||||||||
| 9 | Are we supporting fulfillment notifications in 3.6 scope? | Wesley Brown to confirm (maybe with help from Nikodem Graczewski (Unlicensed) to understand current state of fulfillment type notifications) |
...