...
| 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 |
|
...
| # | 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