fix: Rescheduling email when there is broken calendar integration #15669
Conversation
|
The latest updates on your projects. Learn more about Vercel for Git ↗︎
2 Skipped Deployments
|
|
This stack of pull requests is managed by Graphite. Learn more about stacking. Join @hariombalhara and the rest of your teammates on |
dosubot
bot
added
bookings
Graphite Automations"Add consumer team as reviewer" took an action on this PR • (07/05/24)1 reviewer was added to this PR based on Keith Williams's automation. |
|
Will discuss it more, but here is my opinion on this PR. The question is how does one consider the rescheduling has been done.
So, if we go with the approach of failing the booking itself if calendar update fails, then the inconsistency won't arise. But that's a big decision and a separate discussion. I think doing the change in the PR atleast improves the situation as DB, email communication and webhooks are in sync as these are the one we control directly. |
|
Discussed internally, we are good to go @Udit-takkar !! Thanks for stopping me and suggesting to discuss it 🙏 |
…roken_calendar_integration
📦 Next.js Bundle Analysis for @calcom/webThis analysis was generated by the Next.js Bundle Analysis action. 🤖 Seventy-eight Pages Changed SizeThe following pages changed size from the code in this PR compared to its base branch:
DetailsOnly the gzipped size is provided here based on an expert tip. First Load is the size of the global bundle plus the bundle for the individual page. If a user were to show up to your website and land on a given page, the first load size represents the amount of javascript that user would need to download. If Any third party scripts you have added directly to your app using the The "Budget %" column shows what percentage of your performance budget the First Load total takes up. For example, if your budget was 100kb, and a given page's first load size was 10kb, it would be 10% of your budget. You can also see how much this has increased or decreased compared to the base branch of your PR. If this percentage has increased by 20% or more, there will be a red status indicator applied, indicating that special attention should be given to this. If you see "+/- <0.01%" it means that there was a change in bundle size, but it is a trivial enough amount that it can be ignored. |
keithwillcode
deleted the
07-05-fix_rescheduling_email_when_there_is_broken_calendar_integration
branch
* commit '0dd3b2562458522ad002b4ea967e2b10855a4ab6': (130 commits) chore: v4.2.5 (calcom#15735) fix: api v2 unit tests (calcom#15733) fix: event type back button (calcom#15722) fix: remove console.log and tsignore apiv2 (calcom#15732) fix: api-v2 controllers e2e tests (calcom#15724) fix: Text in Embed Code Visibility Fixed (calcom#15711) chore: sort calendar crendentials in event manager (calcom#15448) chore: cache org guard and fix roles guard apiv2 (calcom#15719) Revert "fix: Autodetection of time zone only updated default time zone (calcom#15392)" (calcom#15720) feat: add POST end point to mark calls as no-shows (calcom#15690) chore: add i18n to atoms (calcom#15698) fix: set conferencing apps as default (calcom#15376) fix: disable google-meet in user onboarding if google-calendar is not installed (calcom#15702) fix: Rescheduling email when there is broken calendar integration (calcom#15669) chore: v4.2.4 (calcom#15703) fix: 404s becoming 500s (calcom#15696) fix: delete reserved slot on booker unmount (calcom#15700) chore: add caching apiv2 roles guard (calcom#15694) refactor: handleNewBooking calcom#3 (calcom#15612) fix: incorrect booking seats full error on collective seated event (calcom#15602) ... # Conflicts: # packages/emails/templates/attendee-request-email.ts # packages/emails/templates/attendee-was-requested-to-reschedule-email.ts # packages/emails/templates/organizer-cancelled-email.ts # packages/emails/templates/organizer-location-change-email.ts # packages/emails/templates/organizer-payment-refund-failed-email.ts # packages/emails/templates/organizer-request-email.ts # packages/emails/templates/organizer-request-reminder-email.ts # packages/emails/templates/organizer-requested-to-reschedule-email.ts # packages/emails/templates/organizer-rescheduled-email.ts # packages/emails/templates/organizer-scheduled-email.ts
What does this PR do?
The rescheduling emails were not sent in case of a failure with one of the apps/integrations that could be a Calendar App or a conferencing app. This was intentional because a separate Broken Integration Email goes in that case that has the booking details as well as the information on which App is broken. The email has a clear subject inviting the user to take action on the issue.
There are two reasons why it was a problem:
New Approach
Send rescheduled email as well as Broken Integration Email(not fixing the Calendar App Broken integration email in this PR)
I think it is perfectly fine for the organizer to receive two emails in that case. One informing about the reschedule and the other informing about the broken App.
Broken Integration Email
Reschedule Email
Mandatory Tasks (DO NOT REMOVE)
How should this be tested?