Versions Compared

Old Version 10

changes.mady.by.user Josh Zamor

Saved on

compared with

New Version Current

changes.mady.by.user Craig Appl (Unlicensed)

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

#TitleUser StoryLabelImportanceNotes
1SMS and email functionalityAs 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 TanzaniaMust have
2Automatic 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 TanzaniaMust HaveWE NEED TO REVIEW IF THIS IS CURRENTLY A FEATURE OF OPENLMIS V3
3Supervisor Reports and Push Notification InterfaceAs 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

  • see lists of facilities which have not reported yet for the current period, together with the facility’s contact details.  The interface should allow showing of late-reporters across all programs or a selected program.

  • select one or multiple facilities and click on a button leading to an option to send an SMS and/or an  email to the facility(ies) based on a pre-filled template (but editable before sending)

  • in cases where the user is a higher level supervisor (eg zonal), click on a button to notify lower level supervisor (eg district), leading to an option to send an SMS and/or an email to the lower level supervisor based on a pre-filled template (but editable before sending)

    The templates should contain customisable general text as well as placeholders/”form fields” for the facility’s name and the period of the report, which are pre-filled by the system.

4Log of SMS and emails sentAs 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 TanzaniaMust Have

...

#QuestionOutcomeStatus
1For Tanzania user stories: review the users, "so thats" added, review the label, and review the priority level.
2Josh Zamor Do we currently expose the content of email messages that were sent? The Notification service doesn't seem to have a database elementCraig 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?

  • The way I'd approach answering this is to consider what to display to the end user (not admin) when the 3rd party service isn't available.  Still might want to record the message and the status of handing it off to the third party.  If we need to determine if the 3rd party sent it, then we're moving into interop needs. - Josh


4Instead 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.

5Does the user need to be actively connected to the OpenLMIS server to send messages? What features should be available when offline?

6What should we do when the SMS gateway has run out of money and needs to be recharged?

7The current system posts emails in realtime. Do we need to somehow queue messages? What about automated retries?

8Do 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.

  • Fair question.  If the data access is append-only and our selects are based on a user's id, I wouldn't have any concerns for this table guessing that the number of new messages a month is likely below 80k (4000 requisitions in a month * 10 messages per requisition * 10 messages for the order to pod that results)


Out of Scope

Notes from Gap Estimation 4/11/2018

  • Attendees: Matt Berg, Josh Zamor, Ashraf Islam, Craig Appl
  • This would be a new item in the requisition dropdown
  • Choose a requisition period and program
  • You can see a list of facilities who have not submitted a requisition by selected period with facility name and contact information
    • We will display all users in the list
  • Assume connectivity
  • NEW FEATURE IDEA: We could keep a record of how often emails have been sent. When was the last time you reminded them? What logic should we use around this
  • We want to add the ability to modify the message that is sent and 
  • Underlying action is for each person in the list at each facility will receive a message
  • (There's also a map in eLMIS that shows all facilities who haven't reported with drilldown steps)
  • Question: How do we know who is the facility in charge who should receive the message?
    • We have a home facility for each user
  • We may need to show a list of facilities that don't have a user with their home health facility
  • DECISION: FOCUS ON EMAIL AND SHIFT SMS/CHATBOT FEATURES TO ANOTHER DAY
  • Regarding SMS:
    • SMS cost money. Are implementations willing to pay per message for automated messages?
    • Is another technology like a chatbot more appropriate?