feat: expose host meeting token in Platform API v2 for Cal Video (Dai…

[nordam312]

…ly.co)

What does this PR do?

• Fixes Expose Cal Video (Daily.co) host/owner meeting token via Platform API v2 for managed users #28586

Motivation & Context:
When using the Platform API v2 with managed users and Cal Video (Daily.co integration), there was no way to retrieve the host meeting token (meetingPassword) for a booking. This prevented platform consumers from giving their hosts admin/moderator controls in the video call (e.g., mute all, kick, recording).

Solution:
This PR securely exposes the Daily.co hostToken in Platform API v2 booking responses strictly for authorized users (EventType Owners & Admins). It also updates the frontend videos-single-view to accept token as a URL query parameter, enabling URL-based admin access for managed users routing from the Platform API.

Changes:

1. API Types & Schema: Added hostToken property to the [BaseBookingOutput_2024_08_13] schema.

2. Services
   ([output.service.ts] & [bookings.service.ts]

   • Propagated isHostOrAdmin utilizing eventTypeAccessService.userIsEventTypeAdminOrOwner.
   • Extracted meetingPassword exclusively when the recipient has host permissions.

3. Repository layer:
   Ensured references are fetched alongside attendees and user to populate the hostToken.

4. Web App:
   Extracted the URL ?token=... parameter natively using useSearchParams within [JoinCall] in videos-single-view.tsx component logic to initialize the DailyIframe with Host privileges.

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

1. Create a booking:
   Use an eventTypeId that leverages Cal Video (Daily.co) via API v2.
2. Fetch Bookings as Host:
   Issue a GET /v2/bookings/:uid using an API Key authorized out to the Event Organizer.
   • Expected Output: The JSON payload should include hostToken: "eyJhbG..."
3. Fetch Bookings as Attendee/Unauthorized:
   Issue the same GET request but without host privileges.
   • Expected Output: hostToken should be entirely undefined/missing from the payload.
4. Video Validation:
   Visit http://localhost:3000/video/<uid>?token=<hostToken> in an incognito window. You should observe that host-exclusive controls (like Mute All) are enabled.

Checklist

• I have read the contributing 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
• My PR is small/concise (<500 lines or <10 files)

[coderabbitai]

No actionable comments were generated in the recent review. 🎉

ℹ️ Recent review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 0d6a69ab-b371-4783-abe1-15ee6eda2c81

📥 Commits

Reviewing files that changed from the base of the PR and between 877cb1c and 248572c.

📒 Files selected for processing (1)

• apps/api/v2/src/ee/bookings/2024-08-13/services/bookings.service.ts

---

📝 Walkthrough

Walkthrough

Repository queries were updated to include the references relation when loading bookings. The bookings service now computes and forwards userIsEventTypeAdminOrOwner into output formatting calls. Output service methods accept an isHostOrAdmin flag and derive a hostToken from booking references when that flag is true. Booking output types gained an optional hostToken field. The web video view now prefers a token query parameter when resolving meeting passwords.

🚥 Pre-merge checks | ✅ 4 | ❌ 1

❌ Failed checks (1 warning)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.

✅ Passed checks (4 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title accurately summarizes the main change: exposing the host meeting token in Platform API v2 for Cal Video.
Description check	✅ Passed	The description is comprehensive and directly related to the changeset, explaining the motivation, solution, and implementation details.
Linked Issues check	✅ Passed	The PR fully addresses issue #28586 by implementing all key requirements: exposing hostToken for authorized users, fetching references in repositories, propagating authorization checks, and updating the frontend to accept token query parameters.
Out of Scope Changes check	✅ Passed	All changes are directly scoped to the requirement of exposing host tokens in Platform API v2; no unrelated modifications are present.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

Actionable comments posted: 1

🧹 Nitpick comments (1)

apps/api/v2/src/ee/bookings/2024-08-13/services/output.service.ts (1)

86-86: Consider making references optional in the type for defensive coding.

The references field is typed as required, but the code defensively uses optional chaining (databaseBooking.references?.find). While all repository methods feeding into this service have been updated to include references, typing it as optional (references?: ...) would make the type more accurately reflect the runtime safety pattern and prevent future regressions if a new repository method is added without references.

♻️ Suggested change

-  references: { type: string; meetingPassword: string | null }[];
+  references?: { type: string; meetingPassword: string | null }[];

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In `@apps/api/v2/src/ee/bookings/2024-08-13/services/output.service.ts` at line
86, The references property on the Booking output type is declared as required
but the code (in output.service.ts) defensively accesses
databaseBooking.references using optional chaining; change the declaration of
references to be optional (e.g., references?: { type: string; meetingPassword:
string | null }[] ) so the type matches runtime usage and prevents future
regressions—update the type definition that contains references (the
booking/output type used in the OutputService logic) accordingly.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Inline comments:
In `@apps/api/v2/src/ee/bookings/2024-08-13/services/bookings.service.ts`:
- Around line 752-755: The call to
eventTypeAccessService.userIsEventTypeAdminOrOwner currently casts user to
NonNullable<AuthOptionalUser> which is unsafe because the passed user lacks
isSystemAdmin; instead, construct a properly typed auth user or change the call
to accept the narrower type. Fix by creating a new object (e.g., const authUser
= { ...user, isSystemAdmin: false } or derive isSystemAdmin appropriately) and
pass authUser into userIsEventTypeAdminOrOwner(formatted.eventType), or update
userIsEventTypeAdminOrOwner to accept the incoming `{ email: string; id: number;
orgId?: number }` shape and adjust internals accordingly so no unsafe cast is
used.

---

Nitpick comments:
In `@apps/api/v2/src/ee/bookings/2024-08-13/services/output.service.ts`:
- Line 86: The references property on the Booking output type is declared as
required but the code (in output.service.ts) defensively accesses
databaseBooking.references using optional chaining; change the declaration of
references to be optional (e.g., references?: { type: string; meetingPassword:
string | null }[] ) so the type matches runtime usage and prevents future
regressions—update the type definition that contains references (the
booking/output type used in the OutputService logic) accordingly.

🪄 Autofix (Beta)

Fix all unresolved CodeRabbit comments on this PR:

• Push a commit to this branch (recommended)
• Create a new PR with the fixes

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 3bdf7d12-f8be-4edf-924d-1bd6e4fbcfa5

📥 Commits

Reviewing files that changed from the base of the PR and between f3e07c5 and 877cb1c.

📒 Files selected for processing (6)

• apps/api/v2/src/ee/bookings/2024-08-13/repositories/bookings.repository.ts
• apps/api/v2/src/ee/bookings/2024-08-13/services/bookings.service.ts
• apps/api/v2/src/ee/bookings/2024-08-13/services/output.service.ts
• apps/api/v2/src/modules/booking-seat/booking-seat.repository.ts
• apps/web/modules/videos/views/videos-single-view.tsx
• packages/platform/types/bookings/2024-08-13/outputs/booking.output.ts

[nordam312]

Can someone check my PR please and add the 'run-ci' label so I can check if my changes pass the tests? Thanks! And sorry for the force-push, I was trying to resolve some issues and sync with the main branch. I've now updated the code and it's ready for the run-ci checks