Goals/Scope
Ability to allow the text used on notification email/SMS
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
Background
Different countries have different protocols and customs on how they notify individuals for different message types and what to say
Assumptions
- Notification message text were drafted in consultation with program managers
- The system is connected to a third party SMS gateway or Email system
User Stories
| Title | User Story | Label | Importance | Notes | JIRA Tickets | |
|---|---|---|---|---|---|---|
| 1 | Notifications | As an administrator I want to be able to customize the text to be used for different types of notifications | Notifications | Must have | See screenshot below | |
| 2 | Notifications | As an administrator I want to be able to put values from the database (e.g., name, address) embedded on the text | Notifications | Must have | See screenshot below | Implemented |
| 3 | Send push notifications to users | As an administrator, I need to be able to send push notifications (via email and/or SMS messages) to end users in order to notify them of things like planned system outages. | Malawi-Request | MJ added this because perhaps we can achieve the needs of Malawi with this gap feature. THIS FEATURE IS NOT RELATED TO THIS GAP STORY - WE SHOULD MAKE THIS ANOTHER GAP FEATURE FOR CONSIDERATION | OLMIS-3796 - Getting issue details... STATUS |
Current Features
Numer 1 and 2 from the user stories are currently available in OpenLMIS 3.x. Number 3 above is a separate interface.
OpenLMIS v3.x has the ability to define the messages as part of the build process in each service:
Requisition Service Example:
requisition.email.convertToOrder.subject=Requisition converted to order
requisition.email.convertToOrder.content=Dear {0} {1},\n\nThe Requisition for Program {2} \
and Period {3} has been converted to order.
requisition.email.statusUpdate.subject=Requisition Status Update
requisition.email.statusUpdate.content=Dear ${initiator}:\nThis email is informing you that \
the ${requisitionType} requisition submitted on ${submittedDate} for the Period ${periodName} \
and ${programName} at ${facilityName} has been ${requisitionStatus} by ${author} \
on ${changeDate}.\nPlease login to see the requisition.\n${requisitionUrl}\nThank you.
requisition.email.actionRequired.subject=Action Required
requisition.email.actionRequired.content=Dear ${approver}:\nThis email is informing you that \
the ${requisitionType} requisition submitted on ${submittedDate} for the Period ${periodName} \
and ${programName} at ${facilityName} is ready for review. Please login to review the requisition.\
\n${requisitionUrl}\nThank you.
requisition.email.requisitionApproved.subject=Action Required
requisition.email.requisitionApproved.content=Dear ${user}:\nThis email is informing you that the \
${requisitionType} requisition approved on ${finalApprovalDate} for the Period ${period} \
and ${program} at ${facility} is ready to be converted to an order. Please login to convert \
the requisition to an order.\n${url}\nThank you.
These messages are also available to be translated using Transifex into the local language.
Links to all services:
Diagrams
Dependencies
| Description | Link |
|---|---|
Open Questions
Below is a list of questions to be addressed as a result of this requirements document:
| # | Question | Outcome | Status |
|---|---|---|---|
| 1 | Ashraf How often do these messages change? | Rarely | Helps with future adoptions without the need to |
| 2 | Is a UI really required? | Yes | |
| 3 | If required, what is an appropriate syntax to reference the database fields? (groovy is popular) |
Out of Scope
Notes from Gap Estimation 4/11/2018
- Attendees: Matt Berg, Josh Zamor, Ashraf Islam, Craig Appl
- OpenLMIS tends to be implemented at the country level
- We could, in theory use Transifex to manage
- Today, there's no configurability of messages inside the application while it's running.
- If we want to have admin screens to be able to save these messages, each service needs to have storage and some admin screen to be able to change those values.
- 4 services need a way to store their messages and update them
- We need to define a set of choices that are available as database fields