Difference between revisions of "FloodNotifications"

From floodzilla-wiki
Jump to navigation Jump to search
(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 ===
+
== 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

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.