Add guest management functionality to existing bookings

[zaibkhan]

No description provided.

[codoki-pr-intelligence]

Codoki PR Review

Summary: Tighten guests schema validation, prevent duplicates
What’s good: Good modularization: added lazy-loaded MultiEmail and i18n keys; email template exports are clean and consistent.
Review Status: ❌ Requires changes
Overall Priority: High
Review Update:
• Coverage: Reviewed all 15 files across 2 batches

Issues (Critical & High only)

Severity	Issue	Why it matters
High	Correctness — Admin/owner authorization uses && instead of ||	…/bookings/addGuests.handler.ts Authorization combines admin and owner with &&, which requires a user to be both; this likely blocks legitimate admin/owner access. Use logical OR so either role suffices, matching the intent implied by the variable name.
High	Correctness — Uses caller credentials instead of organizer for calendar...	…/bookings/addGuests.handler.ts Calendar updates should run under the organizer’s account; using the caller’s credentials (attendee/admin) can fail or update the wrong calendar. Use the booking organizer’s user object.
High	Correctness — Mailer uses unfiltered guest list (blacklist/duplicates l...	…/bookings/addGuests.handler.ts You’re emailing the original input, which may include blacklisted, existing, or duplicate addresses. Send only the filtered set, and consider normalizing to lowercase/trim when filtering to avoid case-based blacklist bypass.

Showing top 3 issues. Critical: 0, High: 3. See inline suggestions for more.

Key Feedback (click to expand)

• Needs improvement: Strengthen server-side schema: ensure bookingId is a positive integer, guests array is non-empty, emails are normalized (trim/lowercased), and duplicates are rejected.
• Testing: Add schema tests for: (1) duplicate emails (e.g., ['a@x.com','A@x.com ']), (2) empty guests array, (3) invalid bookingId (0, -1, 1.5), and (4) mixed whitespace in emails to confirm normalization.
• Documentation: Document that guest emails are trimmed, lowercased, and deduplicated on the server, and clarify any hard limits (max guests per request) if applicable.
• Compatibility: Ensure other consumers using addGuests respect the new validation (positive int bookingId, non-empty unique guests). Frontend should surface the 'emails_must_be_unique_valid' message.
• Performance: No significant concerns; the Set-based uniqueness check is O(n) and appropriate for typical guest list sizes.
• Security: No direct security issues surfaced in the provided diff; recommend adding a sane cap on guest list length server-side to avoid abuse.
• Open questions: Should bookingId strictly be an integer? Do we have a maximum allowed number of guests to guard against abuse (e.g., 100+)?

Confidence: 2/5 — Not ready to merge (3 high · status: Requires changes)

React with 👍 or 👎 if you found this review useful.

[codoki-pr-intelligence]

⚠️ High: Authorization combines admin and owner with &&, which requires a user to be both; this likely blocks legitimate admin/owner access. Use logical OR so either role suffices, matching the intent implied by the variable name.

Suggested change

	const isTeamAdminOrOwner =
	```suggestion
	const isTeamAdminOrOwner =
	(await isTeamAdmin(user.id, booking.eventType?.teamId ?? 0)) ||
	(await isTeamOwner(user.id, booking.eventType?.teamId ?? 0));

[codoki-pr-intelligence]

⚠️ High: Calendar updates should run under the organizer’s account; using the caller’s credentials (attendee/admin) can fail or update the wrong calendar. Use the booking organizer’s user object.

Suggested change

	const credentials = await getUsersCredentials(ctx.user);
	```suggestion
	const credentials = await getUsersCredentials(booking.user);
	const eventManager = new EventManager({
	...booking.user,
	credentials: [...credentials],
	});

[codoki-pr-intelligence]

⚠️ High: You’re emailing the original input, which may include blacklisted, existing, or duplicate addresses. Send only the filtered set, and consider normalizing to lowercase/trim when filtering to avoid case-based blacklist bypass.

Suggested change

	await sendAddGuestsEmails(evt, guests);
	```suggestion
	await sendAddGuestsEmails(evt, uniqueGuests);

[codoki-pr-intelligence]

🔷 Medium: The schema allows any number (including non-integers) for bookingId and accepts an empty guests array and duplicate emails with differing cases/whitespace. This can cause duplicate invitations and ambiguous server behavior. Normalize, enforce uniqueness, require at least one guest, and constrain bookingId to a positive integer.