Versions Compared

Key

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

...

#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