Calendar events should be able to remind you before meetings occur.
Revisions and Commits
|Open||epriestley||T7924 Unprototype Calendar (v1)|
|Resolved||epriestley||T7931 Create Calendar triggers which notify users before meetings|
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.