feat: Add Daily Digest emails

[rjackson]

What does this PR do?

This PR adds Daily Digest emails to Cal.com to notify organisers of any bookings they have scheduled in the next 24 hours.

Daily Digest emails are disabled by default, and can be enabled in a new "Notifications" settings page. Users can also choose what time they want to receive their daily digests (at a quarter-hour resolution).

To implement daily digests, I have added a new cron API endpoint (similar to how bookingReminder.ts), which:

1. Finds all users who want to receive daily digests at the current time (within 5 minutes or so, to tolerate minor delays in running the cron)
   • User's daily digest times are local to their timezone, so we use a little bit of Postgres trickery to convert them to UTC and compare them against the database's time
2. For each user, find all of their accepted bookings in the next 24 hours
   • I was originally thinking of aligning the search to a locale-specific day boundaries, but I think its safer and easier to do a blanket 24 hour search. For most users whose availability is standard working hours the result is pretty much identical. For any users who have late night schedules, the 24 hour search will just pick up all relevant records – instead of us having to think about and resolve edge cases
3. Construct and send a daily digest email to that user, containing those bookings

I'm currently raising this PR as a draft to seek feedback & input whilst I'm still working on the feature, particularly relating to design elements.

Fixes #1660

Help required (design) 🙏

This work introduces two new UI elements:

• Notifications settings page
• Daily Digest email

I've done my best to style these so they're not absolutely offensive, but they could certainly use some design input and tweaks before we unleash these on the Cal.com userbase.

The notifications page is fairly inoffensive. Its biggest problem is that it only contains a setting for Daily Digest emails. This is something we can build out over time.

The Daily Digest email probably needs the most help. All other booking-related emails from Cal.com are focused on a single booking at a time, and their UIs are therefore fairly spaced out and detailed. For the Daily Digest email, I've tried to keep things brief, so its easy to understand at-a-glance what's coming up, and a bit more condensed – so there's a clear distinction between bookings. I think the current design is servicable, but it doesn't ✨ spark joy ✨

Current designs:

Subject	Screenshot
Notifications page
Daily Digest email

Environment: Staging(main branch) / Production

Type of change

• New feature (non-breaking change which adds functionality)

How should this be tested?

TODO: To be written up (most complications re: timezone handling)

Checklist

• I haven't checked if my changes generate no new warnings
• I haven't added tests that prove my fix is effective or that my feature works
• I haven't checked if new and existing unit tests pass locally with my changes

TODO

• [ ] Design review & tweaks to notifications page
• [ ] Design review & tweaks to Daily Digest email
• [ ] Write plaintext version of the email, mirroring contents of final HTML design
• [ ] Write up testing of daily digest email
• [ ] Explore automated testing for daily digest email?
• [ ] Self-review of final code

/claim #1660

[vercel[bot]]

The latest updates on your projects. Learn more about Vercel for Git ↗︎

Name	Status	Preview	Comments	Updated (UTC)
ui	✅ Ready (Inspect)	Visit Preview	💬 Add feedback	Jun 8, 2023 6:23pm

[vercel[bot]]

@rjackson is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[socket-security[bot]]

👍 Dependency issues cleared. Learn more about Socket for GitHub ↗︎

This PR previously contained dependency changes with security issues that have been resolved, removed, or ignored.

Next steps

Take a deeper look at the dependency

Take a moment to review the security alert above. Review the linked package source code to understand the potential risk. Ensure the package is not malicious before proceeding. If you're unsure how to proceed, reach out to your security team or ask the Socket team for help at support [AT] socket [DOT] dev.

Remove the package

If you happen to install a dependency that Socket reports as Known Malware you should immediately remove it and select a different dependency. For other alert types, you may may wish to investigate alternative packages or consider if there are other ways to mitigate the specific risk posed by the dependency.

Mark a package as acceptable risk

To ignore an alert, reply with a comment starting with @SocketSecurity ignore followed by a space separated list of package-name@version specifiers. e.g. @SocketSecurity ignore [email protected] bar@* or ignore all packages with @SocketSecurity ignore-all

[github-actions[bot]]

📦 Next.js Bundle Analysis for @calcom/web

This analysis was generated by the Next.js Bundle Analysis action. 🤖

New Page Added

The following page was added to the bundle from the code in this PR:

Page	Size (compressed)	First Load	% of Budget (350 KB)
/settings/my-account/notifications	253.94 KB	404.78 KB	115.65%

[socket-security[bot]]

New and updated dependency changes detected. Learn more about Socket for GitHub ↗︎

Packages		Version	New capabilities	Transitives[^1]	Size	Publisher
@faker-js/faker	🆕	8.0.2	None	+0	9.83 MB	shinigami92
[^1]: https://docs.socket.dev

[github-actions[bot]]

This PR is being marked as stale due to inactivity.

[github-actions[bot]]

This PR is being closed due to inactivity. Please reopen if work is intended to be continued.

[rjackson]

I will come back to this when I have time 😄

Wider architectural question relevant to this work is what our execution time budget is for api/cron calls, and whether these cron endpoints will hold up as Cal.com scales & usage increases (our cron exec times most likely being affected by DB & N * third-party latencies, and possibly memory limits?).

I don't know if these API endpoints end up being "Serverless functions" or "Edge functions" in Vercel's world, which have the following timeouts:

Limit	Hobby	Pro	Enterprise
Serverless Function Execution Timeout (Seconds)	10	60	900
Edge Function Initial Response Timeout (Seconds)	30	30	30
Proxied Request Timeout (Seconds)	30	30	30

We introduced Upstash in #9514, so if it ever looks like we're pushing execution time limits in our API functions we might be able to swap over to re-using Upstash as a queueing system (their qstash service looks helpful for this, although I've not taken a detailed look at it)

None of this is relevant to the short-term dev work on this PR, but I did want to get my thoughts written down before I forgot them :)

[wesleymatosdev]

@rjackson, do you still plan to work on this? I was thinking about attempting to fix the issue