Requisition - Customizable notification messages
Goals/Scope
Out of date
This requirements page has been replaced by Customizable notifications
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
User Stories
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
OpenLMIS: the global initiative for powerful LMIS software