Difference between revisions of "FloodNotifications"
(Created page with "== Flood Notifications == We intend to build a system which will allow users to sign up for notifications when a particular set of gages they're interested in has reach flood...") |
|||
| Line 6: | Line 6: | ||
* A user will be able to give an email address which will receive timely notifications of flood status changes. | * A user will be able to give an email address which will receive timely notifications of flood status changes. | ||
| + | * Various kinds of events can be separately subscribed to per gage: | ||
| + | ** Flood status begins (define a notification water level threshold per gage?) | ||
| + | ** Road underwater | ||
| + | ** Road clear | ||
| + | * When it becomes possible to predict flood events, each predictable event should have a separate notification | ||
==== Possible Requirements ==== | ==== Possible Requirements ==== | ||
| Line 12: | Line 17: | ||
** Text message? | ** Text message? | ||
** Phone calls? | ** Phone calls? | ||
| + | |||
| + | * Other notification events that are not per-gage | ||
| + | ** Region-wide "flood event starting"? | ||
==== Explicit Non-Requirements ==== | ==== Explicit Non-Requirements ==== | ||
| Line 19: | Line 27: | ||
=== Open Questions === | === Open Questions === | ||
| − | * How frequently will notifications go out? | + | * How frequently will notifications go out? |
| + | * Do we need to have per-user or per-gage memory of last time a notification happened for a particular gage to avoid spam? (example: water level reaches road, goes below road level, goes above, all within a short period of time) | ||
| + | * Do we need to track history of notifications we sent? If so, how and where? | ||
| − | + | == Building Blocks == | |
This will depend on implementing LoginAndSecurity. Also, future-flood notifications will depend on FloodForecasting. | This will depend on implementing LoginAndSecurity. Also, future-flood notifications will depend on FloodForecasting. | ||
| + | |||
| + | === Email Notifications === | ||
| + | |||
| + | Doing email notifications will depend on (at least) having these features: | ||
| + | |||
| + | ==== Email address verification ==== | ||
| + | Add a workflow for verifying email addresses: | ||
| + | * Remember verification status (flag already exists in database; need to verify it works and clear all existing statuses) | ||
| + | * Clear verified flag if email address changes | ||
| + | * Generate and send 'click here to verify' email | ||
| + | * Build 'click here to verify' page | ||
| + | * Subscribe UI needs to show if email address is pending (or prevent subscribing until verified) | ||
| + | ** add email verify status to AuthenticateResult so UI has access | ||
| + | |||
| + | ==== Subscription management ==== | ||
| + | |||
| + | Each individual event that can be subscribed to will need a subscribe/unsubscribe UI. | ||
| + | |||
| + | Additionally it probably makes sense to have a single "Manage my subscriptions" page. | ||
| + | |||
| + | There will also need to be a simple "Unsubscribe me from all notifications" page that the email notifications can link to. | ||
| + | |||
| + | ==== Background processing ==== | ||
| + | |||
| + | A background task will run at some appropriate frequency to monitor the state of all notifiable events. | ||
Revision as of 16:25, 20 April 2020
Contents
Flood Notifications
We intend to build a system which will allow users to sign up for notifications when a particular set of gages they're interested in has reach flood stage, and again when the waters have receded.
Requirements
- A user will be able to give an email address which will receive timely notifications of flood status changes.
- Various kinds of events can be separately subscribed to per gage:
- Flood status begins (define a notification water level threshold per gage?)
- Road underwater
- Road clear
- When it becomes possible to predict flood events, each predictable event should have a separate notification
Possible Requirements
- Other notification channels besides email
- Text message?
- Phone calls?
- Other notification events that are not per-gage
- Region-wide "flood event starting"?
Explicit Non-Requirements
- We will not support sending notifications to non-registered users (i.e. you can't just give us an email address, you have to create an account with a password)
Open Questions
- How frequently will notifications go out?
- Do we need to have per-user or per-gage memory of last time a notification happened for a particular gage to avoid spam? (example: water level reaches road, goes below road level, goes above, all within a short period of time)
- Do we need to track history of notifications we sent? If so, how and where?
Building Blocks
This will depend on implementing LoginAndSecurity. Also, future-flood notifications will depend on FloodForecasting.
Email Notifications
Doing email notifications will depend on (at least) having these features:
Email address verification
Add a workflow for verifying email addresses:
- Remember verification status (flag already exists in database; need to verify it works and clear all existing statuses)
- Clear verified flag if email address changes
- Generate and send 'click here to verify' email
- Build 'click here to verify' page
- Subscribe UI needs to show if email address is pending (or prevent subscribing until verified)
- add email verify status to AuthenticateResult so UI has access
Subscription management
Each individual event that can be subscribed to will need a subscribe/unsubscribe UI.
Additionally it probably makes sense to have a single "Manage my subscriptions" page.
There will also need to be a simple "Unsubscribe me from all notifications" page that the email notifications can link to.
Background processing
A background task will run at some appropriate frequency to monitor the state of all notifiable events.