Emails for admin tasks

[PhantomWatson]

General

• [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\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)

• [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