Goals/Scope
Ability to set users to be opted out of automated emails
Status in eLMIS: Implemented.
Status in OpenLMIS: Not Implemented
Priority: High priority for Tanzania, Zanzibar, Zambia
Background
Some users may not like too many automated emails
Assumptions
User is registered with the database and have roles assigned
User Stories
| Title | User Story | Label | Importance | Notes | JIRA Tickets |
|---|
| 1 | Users | As an admin I should be able to respect a user's wish to be opted out of automated email - user can opt out of emails from their user profile page
 - admin can opt out of emails from the edit user page
| Users | Must have | See screenshot below - What email notifications are impacted (requisitions and fulfillment)? Are their any categorizations for email notifications?
- Is there a need to view and update multiple users in bulk or batch?
- A user can opt-out of business oriented notifications from OpenLMIS, but they cannot opt-out of system notifications such as reset password or email verification.
|
|
| 2 | Consolidating notifications | As a storeroom manager, I would like to be able to have email notifications aggregated so that i do not get an email for each action to be taken for a facility. - Can we aggregate notifications by a user, or by a facility?
|
|
| MJ added this to the gap analysis because I believe the request from Malawi represents the desire for users to either opt out of email notifications or consolidate. |  |
Diagrams
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.
Affected screen in OpenLMIS: (Administration>Users>Edit User Roles)
Business Logic:
- If the user has a supervisory role, display a checkbox to opt-out of emails globally
Microservice Changes:
- We may need to add a check to the requisitions microservice that checks if the user has opted out of emails during the process of email generation
Dependencies
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 |
Open Questions
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 | Is the need to turn all of them off globally or one by one? |
|
|
| 2 | Should this be something that the Administrator only has access to, or should the user also have the ability to do this on their own account? |
|
|
| 3 | Please validate this assumption: The opt out of email option is related to a user's role and should be implemented on the roles screen |
|
|
| 4 | Is there a specific subset of emails that need to be opted out of? For example, users should not be able to opt out of emails sent by administrators and critical notifications, but they may want to opt out of requisition approval notifications |
|
|
| 5 | There was a recent request on a product committe call to create a daily summary email of activity. Should this be included in the scope? |
|
|
| 6 | Ashraf, can you define the meaning of "supervisory emails" in the screenshot? |
|
|
Out of Scope
Notes from Gap Estimation 4/11/2018
- Attendees: Matt Berg, Josh Zamor, Ashraf Islam, Craig Appl
- Add a checkbox to the user's profile page that allows them to opt out of supervisory emails.
- Users must still receive emails for their facility
- We should consider allowing the notification service to choose this option for supervision
- Maybe we could have a list of your active subscriptions and then opt out of each subscription
- DECISION - We will opt out of all supervision notifications
- Don't take away the auditability of each notification that was generate
- Log all notifications in the system where they are generated and log where it was shutdown by the notification service
- We need to add an audit log for the notification service that logs if a user is muted (make sure this logs the content as well)
- Question: Does an admin need to view who is currently subscribed to notifications?
Meeting Notes from requirements meeting Tuesday June 12, 2018
Attendees: Sam Im (Deactivated), Chongsun Ahn (Unlicensed), Nikodem Graczewski (Unlicensed), Łukasz Lewczyński (Deactivated), Nuran Idris (Unlicensed), Douglas Khumalo (Unlicensed), Joseph Mtenje (Unlicensed), Samson Thyolani (Unlicensed)
Consolidated emails for warehouse members (OLMIS-3147)
- 80 + facilities for one warehouse (Lilongwe - CMST)
- One notification that says # of facilities have placed an order
- Ability to opt-out of emails
- Categorized notifications by action: submit, authorize, approve, second approval, convert to order
- Categorized by type of notification: requiring action, confirmation, information
- Specify how frequently I receive emails (aggregated, once a day at a scheduled time)
What are the needs?
- One user receives multiple (80*5) notifications?
- They create email alerts so they go to one folder and then are just automatically marked as read.
- The CMST users need to act when they receive notifications
- Option 1: leave it at the discretion of the user to decide to receive email notifications
- Option 2: aggregate notifications by district so that the CMST manager receives one email with some list of # of facilities that are ready for processing (district, program, reporting period)
- After CMST has converted to order, they receive an email Transfer Failed, for every order (400+ emails)
- Option 3: consolidate by status: receive notifications by requisition status (submit, authorize, approve, second approval, convert to order, transfer failed (or transfer successful if sent to ERP)
- How frequently are actions completed?
- Is it useful to have an opt-out vs opt-in, so for a user to receive no notifications? Nuran: Yes
- Is it ok that we just have consolidation or filtering? Filtering means to choose to not receive some of the notifications (I only want approve, not submit, not convert to order)? Nuran: Yes
- If we built consolidate emails to once a day, but do not filter out emails, is this ok?
- Or the user can opt-out of categories, then they are still receiving 400+ emails for one type of category? Nuran: Some users don’t like notifications at all, some users only want to see emails that require action for them. They want to know when a new order has been received. This reminds them that they need to log into the system. I don’t know about the district requirements. Douglas: They want to know # of facilities that have requested for orders.
- Do they want to receive them as they come in? Not the next morning? Nuran: They would like to receive them by district. Once all the forms for a particular district are fully approved, they can go in and process them. They process by district. All the facilities must have reported and been approved before they can act on them.
- The problem is that there are too many emails for users to filter through. We can choose which ones you want to receive and which ones you don’t. One email a day for your district? Future enhancement
- CMST would require that they receive a notification as soon as a facility approves their order, that it’s ready for convert to order action. A daily digest would not be helpful because they need to act on orders.
- They receive an email to convert to order, and that the transfer is failed
- Joseph: Normal orders, vs emergency orders: they process normal orders at the beginning of their day. For emergency orders they need to process it right away. When it’s an emergency they should get an email right away, and then for the normal orders its digested at a scheduled time.
- Do they want a single email, or the ability to choose which emails they receive?
- Nuran: I agree that it might be helpful to separate by normal vs emergency.
- Maybe notifications sent every 8 hours or 12 hours.
- CMST needs a daily digest that lists District A, the following facilities have forms that are waiting for an action.
- # of facilities and facility names and status or action (is the district name available to add to this?) The status could be helpful in the email.
- Joseph: Another problem is receiving notifications for orders that have zero quantities (this is an existing ticket that we could work on too)
- When we want to consolidate emails, we want to group them by a certain status? If we get a daily digest do we want separate emails that show as submitted, approved, etc?
- One email with the latest status? This may be harder to implement.
- Multiple emails with different statuses.
4: One consolidated email with all statuses by a user?
-
- Concern: we are trying to tackle a specific problem, but we may want to make it configurable for the larger audience.
- Concern: daily digest may start to look like a report, and then the notifications are also lost.