Nikodem Graczewski (Unlicensed) can't attend so we won't make a decision, however we will cover where the conversation is at and ask if anyone has any questions / comments.
That the message shouldn't be delayed, put in a digest, etc
That user preferences should be ignored. Used by forgotten password flow.
Is important implies too wide of a definition for this? What do we mean by important?
Notes
SMS
Govt already has a way to get free SMS
RapidPro can be costly to run, usually using the self-hosted TextIt is cheaper.
At OpenLMIS scale, it could be a low enough volume to use the direct phone integration (though rarely do MoH like this idea)
API connection to telco's SMS gateway (probably Kannel) usually takes an hour or so to configure
RapidPro could take on more of our lower priority scope:
managing message content (translations)
digests (with a well crafted flow)
If we redesigned all of Notifications (including email, etc) around TextIt/RapidPro, we could be introducing significant costs to implementer.
Decision needed in 2-3 sprints, make it in sprint 118
We'll keep up momentum, this week or next (forum post)
Notifications knowledge from eLMIS:
Country email limit, however no country wanted to pay for higher volume emails (over 500, 1000?)
20k emails a day, 90% are bouncing? Mark user account's email as bouncing.
Users would mass-migrate from one domain to another
It'd be useful to try to build two-way Notifications (e.g. unsubscribe), measuring whom is actively clicking on links in the email. (Service such as MailChimp)
DHIS2
Forum post and software spec (add links)
Overall goal is to post aggregate info (indicators, meta, periods) and get to DHIS2
Scope under discussion:
Reporting stack to be used for aggregation, visible to an OLMIS admin, and made available
(needs a decision): Transport & Crosswalk fields/meta data and make indicators available to a DHIS2 system
Actual transportation of data from OpenLMIS to DHIS2
could be a 3rd party system. i.e. interop layer (OHIE)
in practice it tends to be the client system responsible for sending aggregate data to DHIS2 (as server)
Work in sprint 117 is on building indicators
Before sprint 118 we'll (as in Product Owner) be making a decision on scope (2) above