[x] Users opt-in to CBER and/or ICI admin task emails
CBER
[x] When a survey gets deactivated: Time to deliver Presentation A or C materials to ICI
[x] Preview
[x] Test
[x] When an optional presentation is purchased: Time to deliver Presentation B or D materials to ICI
[x] Preview
[x] Test
ICI
[x] If an active community was created >= 2 hours ago and has no officials survey: Time to create survey
[x] Preview
[x] Test
[x] If an active community was created >= 2 hours ago, has an officials survey, and has no clients: Time to assign a client
[x] Preview
[x] Test
[x] When a community is advanced to Step Two / Three and the corresponding survey has not yet been created: Time to create and link a survey
[x] Preview
[x] Test
[x] If a survey was created >= 2 hours ago, has no responses, and is not active: Time to activate survey
[x] Preview
[x] Test
[x] When presentation materials are delivered and a presentation has not been scheduled: Time to schedule presentation
[x] Preview
[x] Test
CBER and ICI
[x] When community is advanced to Step Four: Time to deliver policy development
[x] Preview
[x] Test
When done
[x] Opt-in CBER and ICI accounts for appropriate emails
[x] Announce to administrators that this feature is now available, and send them the URL to control opt-ins
[x] Replace AlertsController with a Shell class (with more elegant output)
Move "email frequency threshold" value (2 days) into a configuration property of this new class.
[x] Create cron job that runs all recurring checks for alert conditions (8am-ish EST)
[x] Consider adding task to shell script that sends alerts that are already triggered via events/listeners (so alerts for event-triggered stuff keep getting sent out every few days if they get ignored, and so that alerts about old stuff get sent out at all)
Notes
Alerts that begin with when are triggered by dispatched events, and alerts that begin with if run in daily cron jobs.
Actions triggered by daily cron jobs prevent emails from being sent any more frequently than once per X days (2 days?)
This leaves out prompts to manually advance communities between steps, since that should be happening automatically. For safety, a method could be developed that checks to see if automatic advancement should have happened already and sends an email to ICI if it hasn't.
This leaves out "deactivate survey", since there's currently no response count threshold, response-to-invitation ratio threshold, or time limit to use for automatically considering a survey ready to deactivate.
Phase Two
Classes
\App\AdminAlerts\Alertable (determines if a community meets the conditions for an alert)
\App\AdminAlerts\AlertRecipients (determines who should receive a specific alert, enforcing max frequency per user)
\App\AdminAlerts\Alert (various utility methods, could possibly be phased out)
Alertable
(all methods accept $communityId as its parameter, require community to be active, and return a boolean)
[x] deliverPresentationA() and deliverPresentationC()
Survey is inactive and has responses
Presentation has not been delivered
The corresponding product has been purchased
The presentation has not been opted out of
[x] deliverPresentationB() and deliverPresentationD()
Presentation has not been delivered
The corresponding product has been purchased
The presentation has not been opted out of
[x] createOfficialsSurvey()
Survey does not exist
The corresponding product has been purchased
[x] createOrganizationsSurvey()
Survey does not exist
The corresponding product has been purchased
[x] (this is a change from "community is on Step Three"; requires update to body of email)
[x] createClients()
Community has no clients
[x] activateOfficialsSurvey() and activateOrganizationsSurvey()
Survey is inactive and has no responses
The corresponding product has been purchased
[x] schedulePresentationA() (B, C, and D)
Presentation materials have been delivered
Presentation has not been scheduled
The corresponding product has been purchased
The presentation has not been opted out of
[x] deliverPolicyDev()
Community is on Step Four
Policy dev has not yet been delivered
AlertRecipients
All methods return an array of Users
[x] deliverPresentationA (B, C, and D): CBER
[x] createOfficialsSurvey: ICI
[x] createOrganizationsSurvey: ICI
[x] createClients: ICI
[x] activateSurvey: ICI
[x] schedulePresentation: ICI
[x] deliverPolicyDev: both
AlertSender
[x] Add loop through recipients and "recently sent" check to AlertSender::sendIfValid() so listeners can run it as (new AlertSender($communityId))->sendIfValid('createClients');
[x] Implement in shell, looping through all active communities and valid recipients and calling AlertSender::enqueueEmail($recipient, $alertName)
\App\Shell\AdminAlertsShell
[x] status
For each active community,
For each alert that that community meets the conditions of,
Display number of recipients that would receive an alert and number of recipients who are filtered out due to having been alerted too recently
(Also display no alert conditions met or no subscribers if applicable)
[x] run
For each active community,
For each alert that that community meets the conditions of,
Send alerts
[x] subscribers
Displays a list of
Users subscribed to only CBER alerts
Users subscribed to only ICI alerts
Users subscribed to both alerts
Admins not subscribed to either
AdminAlertMailer
[x] deliverPresentationA()
[x] deliverPresentationB()
[x] deliverPresentationC()
[x] deliverPresentationD()
[x] createOfficialsSurvey()
[x] createOrganizationsSurvey()
[x] createClients()
[x] activateOfficialsSurvey()
[x] activateOrganizationsSurvey()
[x] schedulePresentationA()
[x] schedulePresentationB()
[x] schedulePresentationC()
[x] schedulePresentationD()
[x] deliverPolicyDev()
Wrapup
[x] Remove AlertsController
[x] Remove AdminTaskMailer
[x] Remove QueueAdminTaskEmailTask
[x] Change daily cron job to call bin/cake admin_alerts run
[x] Strip unused methods in Alert
[x] Change maximum alert frequency to once per week
Phase Three
Alertable
[x] deliverPresentationX() alert shouldn't be triggered if (somehow)
the date of the presentation is set,
the date has passed,
and those materials haven't been delivered yet
Testing
AlertableTest should
use fixtures for alertable communities
for each alert type, assert that Alertable considers them alertable
for each alert type, create separate tests that each negate a different alertable criterion in the community and assert that Alertable no longer considers them alertable
[x] deliverPresentationA()
[x] deliverPresentationB()
[x] deliverPresentationC()
[x] deliverPresentationD()
[x] createOfficialsSurvey()
[x] createOrganizationsSurvey()
[x] createClients()
[x] activateOfficialsSurvey()
[x] activateOrganizationsSurvey()
[x] schedulePresentationA()
[x] schedulePresentationB()
[x] schedulePresentationC()
[x] schedulePresentationD()
[x] deliverPolicyDev()
[x] AlertSenderTest should test AlertSender::isRecentlySent() to confirm that it returns false or a DateTime when appropriate
General
CBER
ICI
CBER and ICI
When done
AlertsController
with aShell
class (with more elegant output) Move "email frequency threshold" value (2 days) into a configuration property of this new class.Notes
Phase Two
Classes
\App\AdminAlerts\Alertable
(determines if a community meets the conditions for an alert)\App\AdminAlerts\AlertRecipients
(determines who should receive a specific alert, enforcing max frequency per user)\App\AdminAlerts\AlertSender
(enqueues alert emails)\App\Mailer\AdminAlertMailer
(processes enqueued emails)\App\AdminAlerts\Alert
(various utility methods, could possibly be phased out)Alertable
(all methods accept
$communityId
as its parameter, require community to be active, and return a boolean)deliverPresentationA()
anddeliverPresentationC()
deliverPresentationB()
anddeliverPresentationD()
createOfficialsSurvey()
createOrganizationsSurvey()
createClients()
activateOfficialsSurvey()
andactivateOrganizationsSurvey()
schedulePresentationA()
(B, C, and D)deliverPolicyDev()
AlertRecipients
User
sdeliverPresentationA
(B, C, and D): CBERcreateOfficialsSurvey
: ICIcreateOrganizationsSurvey
: ICIcreateClients
: ICIactivateSurvey
: ICIschedulePresentation
: ICIdeliverPolicyDev
: bothAlertSender
(new AlertSender($communityId))->sendIfValid('createClients');
AlertSender::enqueueEmail($recipient, $alertName)
\App\Shell\AdminAlertsShell
status
no alert conditions met
orno subscribers
if applicable)run
subscribers
Displays a list ofAdminAlertMailer
deliverPresentationA()
deliverPresentationB()
deliverPresentationC()
deliverPresentationD()
createOfficialsSurvey()
createOrganizationsSurvey()
createClients()
activateOfficialsSurvey()
activateOrganizationsSurvey()
schedulePresentationA()
schedulePresentationB()
schedulePresentationC()
schedulePresentationD()
deliverPolicyDev()
Wrapup
AlertsController
AdminTaskMailer
QueueAdminTaskEmailTask
bin/cake admin_alerts run
Alert
Phase Three
Alertable
deliverPresentationX()
alert shouldn't be triggered if (somehow)Testing
AlertableTest
shouldAlertable
considers them alertableAlertable
no longer considers them alertabledeliverPresentationA()
deliverPresentationB()
deliverPresentationC()
deliverPresentationD()
createOfficialsSurvey()
createOrganizationsSurvey()
createClients()
activateOfficialsSurvey()
activateOrganizationsSurvey()
schedulePresentationA()
schedulePresentationB()
schedulePresentationC()
schedulePresentationD()
deliverPolicyDev()
AlertSenderTest
should testAlertSender::isRecentlySent()
to confirm that it returnsfalse
or aDateTime
when appropriate