Skip to content

Code Review Bench PR #25593 - fix(api): return original email without OAuth suffix in bookings#4

Open
tomerqodo wants to merge 2 commits intobase_pr_25593_20260125_7837from
corrupted_pr_25593_20260125_7837
Open

Code Review Bench PR #25593 - fix(api): return original email without OAuth suffix in bookings#4
tomerqodo wants to merge 2 commits intobase_pr_25593_20260125_7837from
corrupted_pr_25593_20260125_7837

Conversation

@tomerqodo
Copy link

Code Review Bench PR calcom#25593

Original PR Title: fix(api): return original email without OAuth suffix in bookings
Original PR Description: ## What does this PR do?

This PR fixes a bug in API v2 (2024-08-13) where emails in booking API responses contained the OAuth client ID as a suffix (+{cuid}). This suffix exists to prevent email collisions between managed users of different OAuth clients.

Fixes calcom#25494 | Linear: CAL-6843

Problem:

  • Managed user emails were returned as: bob+cmidditrv0000mza4q93hbcau@example.com
  • Expected display: bob@example.com

Solution:
To avoid breaking changes for platform customers who may rely on the original email format, we preserve the original email field and add a new displayEmail field with the CUID suffix removed.

Key Changes:

  • Add getDisplayEmail() helper to strip CUID suffix from emails
  • Add displayEmail field to all relevant response objects
  • Keep original email field unchanged for backwards compatibility

Regex pattern used: /\+[a-zA-Z0-9]{25}/ (CUID format, consistent with google-calendar.service.ts)

Affected Fields

Field Value
hosts[].email bob+{cuid}@example.com (unchanged)
hosts[].displayEmail bob@example.com (new)
attendees[].email bob+{cuid}@example.com (unchanged)
attendees[].displayEmail bob@example.com (new)
bookingFieldsResponses.email bob+{cuid}@example.com (unchanged)
bookingFieldsResponses.displayEmail bob@example.com (new)
bookingFieldsResponses.guests[] guest+{cuid}@example.com (unchanged)
bookingFieldsResponses.displayGuests[] guest@example.com (new)
reassignedTo.email bob+{cuid}@example.com (unchanged)
reassignedTo.displayEmail bob@example.com (new)

How should this be tested?

Test Scenario 1 - Managed user as HOST:

  1. Create an event type using managed user's access token
  2. Create booking on that event type (external user booking managed user)
  3. GET /v2/bookings/{uid} with header Cal-Api-Version: 2024-08-13
  4. Verify hosts[].email returns original email with suffix
  5. Verify hosts[].displayEmail returns email without suffix

Test Scenario 2 - Managed user as ATTENDEE:

  1. Create booking where attendee is a managed user
  2. GET /v2/bookings/{uid} with header Cal-Api-Version: 2024-08-13
  3. Verify attendees[].email returns original email with suffix
  4. Verify attendees[].displayEmail returns email without suffix

Test Scenario 3 - Self-booking:

  1. Managed user books their own event type
  2. Verify both email and displayEmail fields are present and correct

Expected result: email fields preserve original value, displayEmail fields return clean email without +{cuid} suffix

Mandatory Tasks (DO NOT REMOVE)

  • I have self-reviewed the code (A decent size PR without self-review might be rejected).
  • I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox. - N/A, OpenAPI spec auto-updated
  • I confirm automated tests are in place that prove my fix is effective or that my feature works.

Human Review Checklist

  • Verify regex pattern /\+[a-zA-Z0-9]{25}/ correctly strips CUID suffixes without affecting normal emails
  • Confirm backwards compatibility: original email field values are unchanged
  • Verify displayEmail is added to all booking output types (hosts, attendees, reassignedTo)

Original PR URL: calcom#25593

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant