|
For a range of user-controlled SMS and email communications to be handled and tracked within OpenLMIS.
Status in eLMIS: Some automated email in use, other features (e.g., user-pushed communications) in eLMIS but not in use
Status in OpenLMIS: Automated email feature in OpenLMIS, other features (push reminders, SMS features) not in OpenLMIS
Priority: High priority
An email notification feature is currently in use in eLMIS - this automatically sends emails as follows:
This feature can be turned on or off for particular users by the user administrator through a tick box “receive supervisory notification email” on the administration screen for that user. It is often turned off as users find the volume of emails too high, and logging into eLMIS to carry out the above approvals/orders work is part of their routine work.
There are currently no emails sent when R&Rs are rejected (to the facility/district who submitted the R&R), although users have said this might be more useful than the above approval notifications.
See the “communications features” section above which describes the current automated email notifications of R&R authorisations/approvals which are in use in eLMIS in Tanzania. Some users request the user administrator to turn this off because the volume of notifications is too high, and the notifications simply remind them to do tasks which are part of their routine work in any case. Users say that it would be more useful to send automated notifications of R&R rejections to the facility/district who submitted the R&R.
In addition there is an email and SMS feature which is in development in eLMIS but not yet completed or in use. This comprises a link from the “reporting rate” report which leads to an interface where the user can manually push reminders to late reporters.
For SMS communications, implementations have budget to support SMS features (which charges per message)
# | Title | User Story | Label | Importance | Notes |
---|---|---|---|---|---|
1 | SMS and email functionality | As a facility I want for a range of user-controlled SMS and email communications to be handled and tracked within OpenLMIS so that functionality can be automated and tracked in the same system. | eLMIS Tanzania | Must have |
|
2 | Automatic R&R rejection notice via email and SMS | As a facility (or districts who submit R&Rs on behalf of facilities reporting on paper) I want to receive automated SMS and email notification when an R&R I submitted has been rejected so that I can address the issue sooner. | eLMIS Tanzania | Must Have | WE NEED TO REVIEW IF THIS IS CURRENTLY A FEATURE OF OPENLMIS V3 |
3 | Supervisor Reports and Push Notification Interface | As a supervisor, I want to have an interface where I can perform functions so that I can perform regular tasks and push reminders to late reporters. | eLMIS Tanzania | Must Have |
|
4 | Log of SMS and emails sent | As a supervisor or administrator I need the system to log SMSes and emails sent so that I have a historical record of the communications sent. | eLMIS Tanzania | Must Have |
Each of the numbered items below relate to the user stories above.
Include any business process mapping, mockups, diagrams or visual designs relating to these requirements. Describes the tasks and the personas who perform those activities. The diagram provides the context for the user stories and serves as a focal point for achieving clarity and agreement among stakeholders. Looks like a standard flow chart.
Identify initial dependencies that are on the critical path for this functionality and may affect the delivery time and serving of business goals. Include links to stories.
Description | Link |
---|---|
Name of story or release | Link to JIRA |
Initial communication between stakeholders and the development team to help understand scope and estimates.
Below is a list of questions to be addressed as a result of this requirements document:
# | Question | Outcome | Status |
---|---|---|---|
1 | For Tanzania user stories: review the users, "so thats" added, review the label, and review the priority level. | Communicate the decision reached | Open, In Progress, Closed, and date of closure |
2 | Josh Zamor Do we currently expose the content of email messages that were sent? The Notification service doesn't seem to have a database element | Craig Appl (Unlicensed): we do not currently. | |
3 | Currently the emails are sent to an email server that performs the actual sending of messages. The email server should keep a unified view of all messages that were sent and OpenLMIS does not track these. Logically, it seems that notifications should be managed in third party tools with a link to the third party tool exposed in OpenLMIS such as an email server or SMS Gateway like RapidPro or frontlineSMS. Should this be considered an integration instead of a feature that should be built into OpenLMIS?
| ||
4 | Instead of SMS, could we use a chat system like Telegram or Facebook messenger? These systems don't charge per message and could be cheaper than SMS. | ||
5 | Does the user need to be actively connected to the OpenLMIS server to send messages? What features should be available when offline? | ||
6 | What should we do when the SMS gateway has run out of money and needs to be recharged? | ||
7 | The current system posts emails in realtime. Do we need to somehow queue messages? What about automated retries? | ||
8 | Do we need to keep a log of the message content, or just a list of which messages were sent? | ||
9 | How long should we keep this log? Does it need to be in a database, or will a text file with logrotate be fine? Database entries could get big quickly.
|