feat: Overlay Calendar v2 and Troubleshooter v2

[kart1ka]

What does this PR do?

• This PR currently only fetches event titles for Google and Office365 Calendar.
• This PR allows users to use Overlay Calendar feature by signing in using their Google and Microsoft Account.
• It also pulls actual event title from the calendar instead of just showing "Busy" for both overlay calendar and troubleshooter.
• This feature upgrade does not need any Google scope changes.
• As per the comment here feat: Overlay Calendar v2 and Troubleshooter v2 #14575 (review), I am sticking with the existing Google OAuth Provider. But since we're using it for both regular and overlay user sign-ups, telling them apart during registration is tricky. So, I couldn't automate Google Calendar setup for overlay users after sign-up. Instead, I'm redirecting them to "/getting-started/connect-calendar" to connect it manually. Let me know if you have any other ideas.

Fixes #12763
Fixes #12752

Type of change

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

How should this be tested?

Testing Overlay Calendar v2

• Just go to a booking page and toggle the Overlay Calendar switch.
• Choose Continue with Google and sign in with a google id.
• You will be taken to "/getting-started/connect-calendar" page.
• Connect your google calendar.
• You will then be redirected to the booking page.
• You will see that now event titles are being displayed instead of just "Busy" for the calendar busy events.

Testing Troubleshooter v2

• Just go to the Troubleshooter and make sure that google calendar is connected and the app is checking google calendar for conflicts.
• You will see that now event titles are being displayed instead of just "Busy" for the calendar busy events.

Mandatory Tasks

• Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.

[vercel]

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

A member of the Team first needs to authorize it.

[github-actions]

Thank you for following the naming conventions! 🙏 Feel free to join our discord and post your PR link.

[github-actions]

📦 Next.js Bundle Analysis for @calcom/web

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

This PR introduced no changes to the JavaScript bundle! 🙌

[sean-brydon]

@kart1ka Everything looks good we just have a unit test failing by the looks of things.

Despite the Unit test:

From a UX standpoint this works pretty damn well thanks for this! Tested

• Troubleshooter
• When authed with a gcal - view another user and test overlay calendar
• Signup a new user (had to toggle off overflow and on again) but i honestly think thats in main also.

Code looks pretty good to me - I'd like a second eye by someone with a bit more appstore experience than myself for these changes

@joeauyeung @zomars would you give this a second pair of eyes before we approve?

[kart1ka]

@kart1ka Everything looks good we just have a unit test failing by the looks of things.

Despite the Unit test:

From a UX standpoint this works pretty damn well thanks for this! Tested

• Troubleshooter
• When authed with a gcal - view another user and test overlay calendar
• Signup a new user (had to toggle off overflow and on again) but i honestly think thats in main also.

Code looks pretty good to me - I'd like a second eye by someone with a bit more appstore experience than myself for these changes

@joeauyeung @zomars would you give this a second pair of eyes before we approve?

@sean-brydon Thanks for the review.

I have fixed the unit test.

Regarding the overflow toggle during signup, you're right—it's present in the main branch too. I've tried to figure out the cause but haven't found a solution yet.

[kart1ka]

I am working on adding the Microsoft Provider for overlay user sign up.

[kart1ka]

I have added getEventList method as a public method on the CalendarService type, Google and office365 calendar service. I have also abstracted the common logic from getAvailability and getEventList method. I am directly calling getEventList instead of getAvailability whenever we need to get event data along with the event title.
Do let me know if any other changes need to be made.

[joeauyeung]

Love the refactor @kart1ka thank you. Tested this both checking availabilities and on the troubleshooter to list calendar event names.

@sean-brydon I'm happy with this from a calendar integration standpoint. I'll leave it to you if you think this is ready to merge.

[keithwillcode]

@zomars @emrysal Added high-risk label to this because it touches auth. Please review before merging.

[sean-brydon]

Tested a fair bit all seems to be working for me. Will wait for a second pair of eyes due to auth changes from @calcom/foundation

Nice work!

[keithwillcode]

/tip 50 @kart1ka

[algora-pbc]

🎉🎈 @kart1ka has been awarded $50! 🎈🎊

• Share on socials
• Give feedback

[PeerRich]

/tip 100

[zomars]

Overall looks like solid work. Very well done @kart1ka. I just have some concerns before merging.

This PR is doing way too much. We have rejected PRs from core contributors for this same reason before. So it would be unfair to give this one a pass. Unless @keithwillcode and @PeerRich says otherwise.

This PR is:

• Adding Azure as an Identity provider
• Doing big changes to google CalendarService
• Doing big changes to microsoft CalendarService

As mentioned in a previous comment, adding Azure as Identity provider may be desirable from product standpoint. But we don't have any previous issues or discussions around it. It would feel weird just adding it out of the blue without that proper discussion.

My next steps would be:

1. Separate the ID provider code into its own PR. Discuss it. Test it. Pass it.
2. Come back to this PR. Test it. Pass it.

This is very nice work. But we need to adhere to the contribution style as much as possible. This is algo a good opportunity on us to improve the docs.

[zomars]

Is adding Azure as an identity provider necessary for this PR to work? If it's not then I would rather have individual PRs that does a single thing well. If it's necessary then I would do the Azure PR first and then this one. The reason is that we need PRs to be easily testable and revertible. If something goes wrong when deploying it will be way harder for us to debug what's actually wrong. So PRs should be as single purpose as possible.

[keithwillcode]

Completely agree with this feedback, @zomars 🙏🏼

[kart1ka]

Hi @zomars
Adding Azure as an Identity Provider is not necessary for this PR to work. I added it because of this comment by sean here: #14575 (comment). The comment mentions that the Identity Providers which are shown in figma design file are to be added. If you would like I can remove the Azure AD Provider from this PR and raise another PR for it which can be merged after thorough testing.
Do let me know how should I proceed.

[PeerRich]

agree here with @zomars

[zomars]

The comment mentions that the Identity Providers which are shown in figma design file are to be added.

I'm not against adding it. Just let's do it with the proper protocols. In a separate PR. With its own issue discussion and approvals. The design is a "desired state" for the app to be in. But we still need to do the work for engineering planning and testing before achieving it.

[kart1ka]

Agreed. I will remove Azure provider from this PR.
Do let me know if any other changes need to be made.