feat: add zapier no-show support#28927
Conversation
|
Welcome to Cal.diy, @thegreatalxx! Thanks for opening this pull request. A few things to keep in mind:
A maintainer will review your PR soon. Thanks for contributing! |
github-actions
Bot
added
app-store
📝 WalkthroughWalkthroughThis pull request extends the Zapier integration with support for no-show booking events. Changes include updating documentation and configuration files (DESCRIPTION.md, README.md, _metadata.ts, config.json) to list "no-show" as an additional booking-event trigger type. A new API route 🚥 Pre-merge checks | ✅ 4 | ❌ 1❌ Failed checks (1 warning)
✅ Passed checks (4 passed)
✏️ Tip: You can configure your own custom pre-merge checks in the settings. ✨ Finishing Touches🧪 Generate unit tests (beta)
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. Comment |
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 2
🤖 Prompt for all review comments with AI agents
Verify each finding against the current code and only fix it if needed.
Inline comments:
In `@packages/app-store/zapier/api/subscriptions/listNoShowBookings.ts`:
- Around line 11-13: The endpoint currently calls validateAccountOrApiKey and
only requests the "READ_BOOKING" permission but then returns profile fields
(user/attendee names, emails, time zones); update the authorization to require
both "READ_BOOKING" and "READ_PROFILE" (mirror listBookings) by changing the
permissions array passed to validateAccountOrApiKey in listNoShowBookings.ts
(the destructured result assigned to authorizedAccount and validKey) so that
profile fields are only returned when READ_PROFILE is granted, or alternatively
strip profile fields if READ_PROFILE is absent—ensure the check location uses
validateAccountOrApiKey and the behavior matches listBookings.
- Line 4: The query that builds the no-show sample list in listNoShowBookings.ts
currently returns bookings where noShowHost or attendee.noShow is set but does
not restrict by booking status; update the query to include status:
BookingStatus.ACCEPTED so only accepted bookings are returned. Locate the query
construction in listNoShowBookings (and related blocks around lines ~18-28) and
add the BookingStatus.ACCEPTED filter (using the BookingStatus enum) alongside
the existing noShowHost / attendee.noShow conditions so the results match the
no-show trigger eligibility.
🪄 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: d7315c20-d814-4e64-843a-02e91585e7d0
📒 Files selected for processing (6)
packages/app-store/zapier/DESCRIPTION.mdpackages/app-store/zapier/README.mdpackages/app-store/zapier/_metadata.tspackages/app-store/zapier/api/index.tspackages/app-store/zapier/api/subscriptions/listNoShowBookings.tspackages/app-store/zapier/config.json
| import type { NextApiRequest, NextApiResponse } from "next"; | ||
|
|
||
| import prisma from "@calcom/prisma"; | ||
| import { WebhookTriggerEvents } from "@calcom/prisma/enums"; |
There was a problem hiding this comment.
Filter no-show samples to accepted bookings.
The query currently returns any booking with noShowHost or attendee noShow, including cancelled/rejected/pending bookings if those flags remain set. Add status: BookingStatus.ACCEPTED so this list mirrors actual no-show trigger eligibility.
🛠️ Proposed fix
-import { WebhookTriggerEvents } from "@calcom/prisma/enums";
+import { BookingStatus, WebhookTriggerEvents } from "@calcom/prisma/enums";
@@
const where = teamId
? {
+ status: BookingStatus.ACCEPTED,
eventType: {
OR: [{ teamId }, { parent: { teamId } }],
},
OR: [{ noShowHost: true }, { attendees: { some: { noShow: true } } }],
}
: {
+ status: BookingStatus.ACCEPTED,
eventType: { userId },
OR: [{ noShowHost: true }, { attendees: { some: { noShow: true } } }],
};Based on learnings, all side effects including no-show triggers are gated on booking.status === ACCEPTED.
Also applies to: 18-28
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/app-store/zapier/api/subscriptions/listNoShowBookings.ts` at line 4,
The query that builds the no-show sample list in listNoShowBookings.ts currently
returns bookings where noShowHost or attendee.noShow is set but does not
restrict by booking status; update the query to include status:
BookingStatus.ACCEPTED so only accepted bookings are returned. Locate the query
construction in listNoShowBookings (and related blocks around lines ~18-28) and
add the BookingStatus.ACCEPTED filter (using the BookingStatus enum) alongside
the existing noShowHost / attendee.noShow conditions so the results match the
no-show trigger eligibility.
| const { account: authorizedAccount, appApiKey: validKey } = await validateAccountOrApiKey(req, [ | ||
| "READ_BOOKING", | ||
| ]); |
There was a problem hiding this comment.
Require profile read permission before returning profile fields.
This endpoint authorizes only READ_BOOKING, but returns user and attendee names/emails/time zones. The existing listBookings endpoint requires both READ_BOOKING and READ_PROFILE before returning attendee email, so this should keep the same permission boundary.
🔐 Proposed fix
const { account: authorizedAccount, appApiKey: validKey } = await validateAccountOrApiKey(req, [
"READ_BOOKING",
+ "READ_PROFILE",
]);Also applies to: 51-79
🤖 Prompt for AI Agents
Verify each finding against the current code and only fix it if needed.
In `@packages/app-store/zapier/api/subscriptions/listNoShowBookings.ts` around
lines 11 - 13, The endpoint currently calls validateAccountOrApiKey and only
requests the "READ_BOOKING" permission but then returns profile fields
(user/attendee names, emails, time zones); update the authorization to require
both "READ_BOOKING" and "READ_PROFILE" (mirror listBookings) by changing the
permissions array passed to validateAccountOrApiKey in listNoShowBookings.ts
(the destructured result assigned to authorizedAccount and validKey) so that
profile fields are only returned when READ_PROFILE is granted, or alternatively
strip profile fields if READ_PROFILE is absent—ensure the check location uses
validateAccountOrApiKey and the behavior matches listBookings.
|
Hi, Severity: action required | Category: security How to fix: Sanitize booking metadata output Agent prompt to fix - you can give this to your LLM of choice:
We noticed a couple of other issues in this PR as well - happy to share if helpful. Found by Qodo code review |
|
This PR has been marked as stale due to inactivity. If you're still working on it or need any help, please let us know or update the PR to keep it active. |
|
Hi, Severity: action required | Category: correctness How to fix: Return standard no-show payload Agent prompt to fix - you can give this to your LLM of choice:
Found by Qodo. Free code review for open-source maintainers. |
|
we've decided to close the issue. |
3 participants
Adds a new listNoShowBookings endpoint and exports it to the Zapier API to support no-show triggers. Updated documentation and app metadata to include no-show event support. Fixes #18992.