What does this PR do?

This PR adds authorization checks to the booking reassignment endpoints in the Platform API v2 to ensure that only authorized users (booking organizers, team admins, or org admins) can reassign bookings.

Link to Devin run:https://app.devin.ai/sessions/6c99f3b7ed764eb5ac23b5c3c422c6b7
Requested by: Volnei Munhoz (volnei@cal.com) /@volnei

Changes Made

• Added authorization validation inBookingsService.reassignBooking() method
• Added authorization validation inBookingsService.reassignBookingToUser() method
• Both methods now useBookingRepository.doesUserIdHaveAccessToBooking() to verify the requesting user has permission to modify the booking
• Returns403 Forbidden when authorization fails

The authorization check verifies that the user is either:

1. The booking organizer (userId matches booking.userId)
2. A team admin of the team that owns the event type
3. An org admin of the organization that owns the team

This follows the same authorization pattern used in the TRPC round-robin reassignment handler.

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 adocumentation change. If N/A, write N/A here and check the checkbox.N/A - This is a security fix that doesn't change the API contract or require documentation updates.
• I confirm automated tests are in place that prove my fix is effective or that my feature works.Note: No existing test infrastructure exists for API v2 services. Manual testing recommended.

How should this be tested?

Prerequisites

• Two user accounts in the system (User A and User B)
• User A should have a round-robin event type with bookings
• User B should NOT be a team member or admin of User A's team

Test Case 1: Unauthorized Reassignment (Should Fail)

1. Create a booking for User A's event type
2. Attempt to reassign the booking using User B's API credentials
3. Expected: Should receive403 Forbidden response
4. Verify: Booking should remain assigned to original host

Test Case 2: Authorized Reassignment (Should Succeed)

1. Create a booking for User A's event type
2. Attempt to reassign the booking using User A's API credentials (or team admin credentials)
3. Expected: Should receive200 OK response with reassigned booking
4. Verify: Booking should be reassigned to new host

API Endpoints to Test

• POST /v2/bookings/{bookingUid}/reassign (automatic reassignment)
• POST /v2/bookings/{bookingUid}/reassign/{userId} (manual reassignment to specific user)

Important Review Points

⚠️Critical areas for review:

1. Authorization Logic Completeness - DoesBookingRepository.doesUserIdHaveAccessToBooking() correctly handle all legitimate access scenarios? Review the implementation atpackages/features/bookings/repositories/BookingRepository.ts:194-224

2. Breaking Changes - Are there any legitimate use cases where users should be able to reassign bookings they don't directly own that this change might break?

3. Edge Cases - How does this handle:

   • Bookings with no associated event type (eventTypeId is null)?
   • Bookings for deleted teams?
   • API key authentication vs OAuth token authentication?

4. Error Handling - Is403 Forbidden the appropriate status code, or should we use404 Not Found to avoid leaking information about booking existence?

5. Testing - Since no automated tests were added (no existing test infrastructure for API v2 services), manual testing is critical before merge.

Checklist

• I have read thecontributing guide
• My code follows the style guidelines of this project
• I have commented my code, particularly in hard-to-understand areas
• I have checked if my changes generate no new warnings