Add guest management functionality to existing bookings#2
Add guest management functionality to existing bookings#2akshayutture-augment wants to merge 1 commit into
Conversation
* feat: ability to add guests via app.cal.com/bookings * fix: some update * fix: minor issue * fix: final update * update * update * add requested changes * fix type error * small update * final update * fix type error * fix location * update calender event --------- Co-authored-by: Somay Chauhan <somaychauhan98@gmail.com>
| if (!booking) throw new TRPCError({ code: "NOT_FOUND", message: "booking_not_found" }); | ||
|
|
||
| const isTeamAdminOrOwner = | ||
| (await isTeamAdmin(user.id, booking.eventType?.teamId ?? 0)) && |
There was a problem hiding this comment.
isTeamAdminOrOwner uses &&, which requires the user to be both admin and owner; given the name/intent, this likely should allow either role. This will incorrectly block team admins or owners from adding guests.
🤖 Was this useful? React with 👍 or 👎
|
|
||
| const uniqueGuests = guests.filter( | ||
| (guest) => | ||
| !booking.attendees.some((attendee) => guest === attendee.email) && |
There was a problem hiding this comment.
Email comparisons for existing attendees use guest === attendee.email, which is case-sensitive; emails should be treated case-insensitively (also applies to the blacklist includes check). This can allow duplicates or bypass blacklisted entries when casing differs.
🤖 Was this useful? React with 👍 or 👎
| await eventManager.updateCalendarAttendees(evt, booking); | ||
|
|
||
| try { | ||
| await sendAddGuestsEmails(evt, guests); |
There was a problem hiding this comment.
Calling sendAddGuestsEmails(evt, guests) uses the original input instead of the actually added uniqueGuests; this can misclassify attendees and send the wrong notification type (e.g., duplicates/blacklisted). Consider passing only the successfully added addresses.
🤖 Was this useful? React with 👍 or 👎
| utils.viewer.bookings.invalidate(); | ||
| }, | ||
| onError: (err) => { | ||
| const message = `${err.data?.code}: ${t(err.message)}`; |
There was a problem hiding this comment.
Building the error toast as ${err.data?.code}: ${t(err.message)} can display undefined: … when code is absent, and the fallback won’t trigger because the string is truthy. This may show awkward messages to users.
🤖 Was this useful? React with 👍 or 👎
No description provided.