...
| Page Properties | ||||||||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
...
Status in OpenLMIS: Partially Implemented. Implementers can change , but not through the UIby editing the strings in each service. Values can come from the database.
Priority: High priority for Tanzania, Zanzibar, Zambia
Background
Different country countries have different protocol protocols and customs on how to 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. |
|
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:
| Code Block | ||
|---|---|---|
| ||
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 |
|---|---|
...
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? | ||
| 2 | Is a UI really required? | ||
| 3 | If required, what is an appropriate syntax to reference the database fields? (groovy is popular) |