Requisition - Customizable notification messages

Target release
Epic	Notifications - UI Customization
Document status	DEAD
Priority	HIGH
eLMIS Status	Implemented
OpenLMIS Status	Partially Implemented
PATH	-
OpenLMIS	Craig Appl (Unlicensed)
JSI	Ashraf Islam (Unlicensed)

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

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 Strings

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