Page MenuHomePhabricator

Create Calendar triggers which notify users before meetings
Closed, ResolvedPublic

Assigned To
Authored By
epriestley
Apr 26 2015, 5:24 AM
Tokens
"Like" token, awarded by peter.schlaile."Like" token, awarded by cmmata."Like" token, awarded by mariokri100."Like" token, awarded by CodeMouse92.

Description

Calendar events should be able to remind you before meetings occur.

Event Timeline

epriestley assigned this task to lpriestley.
epriestley raised the priority of this task from to Normal.
epriestley updated the task description. (Show Details)
epriestley added a project: Calendar.
epriestley added a subscriber: epriestley.

D16752 was approximately the same thing but I think this is a little complicated -- both in general, and for recurring events. I'm also not really sure this should use the trigger system at all.

Using triggers for this is tricky because, among other things:

  • recurring events are hard to attach triggers to;
  • some events have different start times for different users;
  • it would be nice to group all of your events together if you have several events starting at the same time.

Maybe a better approach is to just run a check every ~5 minutes for events starting in the next ~15 minutes, do any notifying we need to do, and then mark who we notified about what somewhere (for "All Day" events, we need to notify west-coast attendees and east-coast attendees at different times, and these notifications probably aren't useful anyway; better would be including them in a 6AM "your schedule today" sort of digest, perhaps).

So I think this looks like:

  • New storage of <parentPHID, instanceStartUTC, userPHID, didNotifyEpoch>.
    • (Maybe this is also a cache of start times to make the scanning cheaper? We need to look ~24 hours ahead to deal with timezones.)
  • New TriggerDaemon phase for scanning Calendar events.
  • When we hit a user to notify, check for other stuff in the next ~hour to notify them of? Maybe v2?
    • Fancier handling for all-day, etc (v2/v3)?
  • When we deliver a notification, mark it in the table. Don't deliver notifications if they're marked.
  • Keep a cursor somewhere? Does that need a new table too? Maybe just keep it in-process and start it at ~15m ago, since un-timely notifications aren't useful anyway?
  • Eventually, preferences.

This ends up essentially all custom so no real overlap with D16752. I think specializing this is probably the right call in the long run, though, since it will be difficult to do any sort of digest/batching if we try to reuse triggers here.

These are very much proof-of-concept for now, but should technically work after D16784. Expected behavior now:

  • If the daemons are running, you'll get a 15-minute reminder email before events start, if you have RSVP'd "Attending", the event was not cancelled, and the event was not imported from somewhere else.
  • We don't end un-timely emails -- if the daemons are down for a bit, we won't generate reminders for past events which we didn't send during the downtime. Theory is: you already missed the meeting and are out of luck. (If they're down for a couple minutes, we'll still send you a "13-minute" reminder instead of a 15-minute reminder or whatever.)

Possible future work:

  • Better handling of all-day events so we don't send you a reminder at midnight (maybe: 7AM digest of events for the day?)
  • Prettier email, maybe add a section like "Agenda" which shows other upcoming events later in the day.
  • Integration with application-level notifications (now, only email)
  • Preference for notifying ("don't remind me about this") and how long in advance to send reminders (30m vs 15m)?
  • Maybe reconsider "only events you are attending" rule?
  • Maybe Herald integration so you can do fancier stuff (webhooks, SMS)?
  • Probably plenty of bugs to fix.