fix: Remove cancel button for past bookings #22667
Conversation
|
@husniabad is attempting to deploy a commit to the cal Team on Vercel. A member of the Team first needs to authorize it. |
WalkthroughRefactors booking action wiring in BookingListItem, consolidating edit action initialization and dialog open handlers. Hides/disables the cancel option for bookings whose end time is past across multiple UI views and adds a tooltip explaining the disabled state. Backend cancellation handler now rejects cancel requests for bookings that have already ended (HTTP 400). Adds a Playwright E2E test asserting the cancel button and related prompt are hidden for past bookings. Estimated code review effort🎯 3 (Moderate) | ⏱️ ~15 minutes Assessment against linked issues
Assessment against linked issues: Out-of-scope changes
Possibly related PRs
✨ Finishing Touches
🧪 Generate 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. 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
SupportNeed help? Create a ticket on our support page for assistance with any issues or questions. CodeRabbit Commands (Invoked using PR/Issue comments)Type Other keywords and placeholders
CodeRabbit Configuration File (
|
Graphite Automations"Add consumer team as reviewer" took an action on this PR • (07/22/25)1 reviewer was added to this PR based on Keith Williams's automation. "Add community label" took an action on this PR • (07/22/25)1 label was added to this PR based on Keith Williams's automation. |
There was a problem hiding this comment.
Actionable comments posted: 0
🧹 Nitpick comments (1)
packages/features/bookings/lib/handleCancelBooking.ts (1)
123-129: Consider using native Date comparison for better performance.The server-side validation logic is correct and essential for preventing past booking cancellations. However, according to the coding guidelines, Day.js methods like
.isAfter()can be slow in performance-critical code. Consider using native Date comparison for better performance:- if (bookingToDelete.endTime && dayjs().isAfter(bookingToDelete.endTime)) { + if (bookingToDelete.endTime && new Date() > new Date(bookingToDelete.endTime)) {This maintains the same functionality while potentially improving performance in this critical validation path.
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (5)
apps/web/components/booking/BookingListItem.tsx(1 hunks)apps/web/modules/bookings/views/bookings-single-view.tsx(2 hunks)apps/web/playwright/booking-pages.e2e.ts(1 hunks)packages/features/bookings/lib/handleCancelBooking.ts(1 hunks)packages/platform/examples/base/src/pages/[bookingUid].tsx(2 hunks)
📓 Path-based instructions (1)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/review.mdc)
Flag excessive Day.js use in performance-critical code. Functions like .add, .diff, .isBefore, and .isAfter are slow, especially in timezone mode. Prefer .utc() for better performance. Where possible, replace with native Date and direct .valueOf() comparisons for faster execution. Recommend using native methods or Day.js .utc() consistently in hot paths like loops.
Files:
packages/platform/examples/base/src/pages/[bookingUid].tsxapps/web/components/booking/BookingListItem.tsxpackages/features/bookings/lib/handleCancelBooking.tsapps/web/playwright/booking-pages.e2e.tsapps/web/modules/bookings/views/bookings-single-view.tsx
🧠 Learnings (3)
packages/platform/examples/base/src/pages/[bookingUid].tsx (4)
Learnt from: eunjae-lee
PR: #22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.
Learnt from: Anshumancanrock
PR: #22570
File: apps/web/modules/signup-view.tsx:253-253
Timestamp: 2025-07-21T21:33:23.343Z
Learning: In signup-view.tsx, when checking if redirectUrl contains certain strings, using explicit && checks (redirectUrl && redirectUrl.includes()) is preferred over optional chaining (redirectUrl?.includes()) to ensure the result is always a boolean rather than potentially undefined. This approach provides cleaner boolean contracts for downstream conditional logic.
Learnt from: alishaz-polymath
PR: #22304
File: packages/features/eventtypes/components/MultiplePrivateLinksController.tsx:92-94
Timestamp: 2025-07-16T06:42:27.024Z
Learning: In the MultiplePrivateLinksController component (packages/features/eventtypes/components/MultiplePrivateLinksController.tsx), the currentLink.maxUsageCount ?? 1 fallback in the openSettingsDialog function is intentional. Missing maxUsageCount values indicate old/legacy private links that existed before the expiration feature was added, and they should default to single-use behavior (1) for backward compatibility.
Learnt from: eunjae-lee
PR: #22106
File: packages/features/insights/components/RoutingFunnel.tsx:15-17
Timestamp: 2025-07-15T12:58:40.539Z
Learning: In the insights routing funnel component (packages/features/insights/components/RoutingFunnel.tsx), the useColumnFilters exclusions are intentionally different from the general useInsightsParameters exclusions. RoutingFunnel specifically excludes only ["createdAt"] while useInsightsParameters excludes ["bookingUserId", "formId", "createdAt", "eventTypeId"]. This difference is by design.
apps/web/components/booking/BookingListItem.tsx (1)
Learnt from: eunjae-lee
PR: #22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.
apps/web/modules/bookings/views/bookings-single-view.tsx (3)
Learnt from: eunjae-lee
PR: #22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.
Learnt from: Anshumancanrock
PR: #22570
File: apps/web/modules/signup-view.tsx:253-253
Timestamp: 2025-07-21T21:33:23.343Z
Learning: In signup-view.tsx, when checking if redirectUrl contains certain strings, using explicit && checks (redirectUrl && redirectUrl.includes()) is preferred over optional chaining (redirectUrl?.includes()) to ensure the result is always a boolean rather than potentially undefined. This approach provides cleaner boolean contracts for downstream conditional logic.
Learnt from: alishaz-polymath
PR: #22304
File: packages/features/eventtypes/components/MultiplePrivateLinksController.tsx:92-94
Timestamp: 2025-07-16T06:42:27.024Z
Learning: In the MultiplePrivateLinksController component (packages/features/eventtypes/components/MultiplePrivateLinksController.tsx), the currentLink.maxUsageCount ?? 1 fallback in the openSettingsDialog function is intentional. Missing maxUsageCount values indicate old/legacy private links that existed before the expiration feature was added, and they should default to single-use behavior (1) for backward compatibility.
🧬 Code Graph Analysis (1)
packages/features/bookings/lib/handleCancelBooking.ts (1)
packages/platform/libraries/index.ts (1)
HttpError(49-49)
🧰 Additional context used
📓 Path-based instructions (1)
**/*.{js,jsx,ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/review.mdc)
Flag excessive Day.js use in performance-critical code. Functions like .add, .diff, .isBefore, and .isAfter are slow, especially in timezone mode. Prefer .utc() for better performance. Where possible, replace with native Date and direct .valueOf() comparisons for faster execution. Recommend using native methods or Day.js .utc() consistently in hot paths like loops.
Files:
packages/platform/examples/base/src/pages/[bookingUid].tsxapps/web/components/booking/BookingListItem.tsxpackages/features/bookings/lib/handleCancelBooking.tsapps/web/playwright/booking-pages.e2e.tsapps/web/modules/bookings/views/bookings-single-view.tsx
🧠 Learnings (3)
packages/platform/examples/base/src/pages/[bookingUid].tsx (4)
Learnt from: eunjae-lee
PR: #22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.
Learnt from: Anshumancanrock
PR: #22570
File: apps/web/modules/signup-view.tsx:253-253
Timestamp: 2025-07-21T21:33:23.343Z
Learning: In signup-view.tsx, when checking if redirectUrl contains certain strings, using explicit && checks (redirectUrl && redirectUrl.includes()) is preferred over optional chaining (redirectUrl?.includes()) to ensure the result is always a boolean rather than potentially undefined. This approach provides cleaner boolean contracts for downstream conditional logic.
Learnt from: alishaz-polymath
PR: #22304
File: packages/features/eventtypes/components/MultiplePrivateLinksController.tsx:92-94
Timestamp: 2025-07-16T06:42:27.024Z
Learning: In the MultiplePrivateLinksController component (packages/features/eventtypes/components/MultiplePrivateLinksController.tsx), the currentLink.maxUsageCount ?? 1 fallback in the openSettingsDialog function is intentional. Missing maxUsageCount values indicate old/legacy private links that existed before the expiration feature was added, and they should default to single-use behavior (1) for backward compatibility.
Learnt from: eunjae-lee
PR: #22106
File: packages/features/insights/components/RoutingFunnel.tsx:15-17
Timestamp: 2025-07-15T12:58:40.539Z
Learning: In the insights routing funnel component (packages/features/insights/components/RoutingFunnel.tsx), the useColumnFilters exclusions are intentionally different from the general useInsightsParameters exclusions. RoutingFunnel specifically excludes only ["createdAt"] while useInsightsParameters excludes ["bookingUserId", "formId", "createdAt", "eventTypeId"]. This difference is by design.
apps/web/components/booking/BookingListItem.tsx (1)
Learnt from: eunjae-lee
PR: #22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.
apps/web/modules/bookings/views/bookings-single-view.tsx (3)
Learnt from: eunjae-lee
PR: #22106
File: packages/features/insights/components/FailedBookingsByField.tsx:65-71
Timestamp: 2025-07-15T12:59:34.389Z
Learning: In the FailedBookingsByField component (packages/features/insights/components/FailedBookingsByField.tsx), although routingFormId is typed as optional in useInsightsParameters, the system automatically enforces a routing form filter, so routingFormId is always present in practice. This means the data always contains only one entry, making the single-entry destructuring approach safe.
Learnt from: Anshumancanrock
PR: #22570
File: apps/web/modules/signup-view.tsx:253-253
Timestamp: 2025-07-21T21:33:23.343Z
Learning: In signup-view.tsx, when checking if redirectUrl contains certain strings, using explicit && checks (redirectUrl && redirectUrl.includes()) is preferred over optional chaining (redirectUrl?.includes()) to ensure the result is always a boolean rather than potentially undefined. This approach provides cleaner boolean contracts for downstream conditional logic.
Learnt from: alishaz-polymath
PR: #22304
File: packages/features/eventtypes/components/MultiplePrivateLinksController.tsx:92-94
Timestamp: 2025-07-16T06:42:27.024Z
Learning: In the MultiplePrivateLinksController component (packages/features/eventtypes/components/MultiplePrivateLinksController.tsx), the currentLink.maxUsageCount ?? 1 fallback in the openSettingsDialog function is intentional. Missing maxUsageCount values indicate old/legacy private links that existed before the expiration feature was added, and they should default to single-use behavior (1) for backward compatibility.
🧬 Code Graph Analysis (1)
packages/features/bookings/lib/handleCancelBooking.ts (1)
packages/platform/libraries/index.ts (1)
HttpError(49-49)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (3)
- GitHub Check: Install dependencies / Yarn install & cache
- GitHub Check: Codacy Static Code Analysis
- GitHub Check: Security Check
🔇 Additional comments (7)
apps/web/components/booking/BookingListItem.tsx (1)
372-374: LGTM! Simplified logic correctly prevents cancellation of past bookings.The condition has been appropriately simplified to remove the cancel action for any past booking, regardless of its confirmation status. This aligns with the PR objective and provides a cleaner, more consistent user experience.
packages/platform/examples/base/src/pages/[bookingUid].tsx (2)
30-30: Good choice using native Date comparison for performance.The use of native
Dateobjects for the time comparison is appropriate and aligns with the coding guidelines that recommend avoiding Day.js methods like.isBefore()in performance-critical code.
134-165: LGTM! Correctly hides reschedule and cancel options for past bookings.The conditional rendering properly restricts access to booking modification options for past bookings, ensuring consistency with the overall PR objective. The logic is clear and the implementation is correct.
apps/web/playwright/booking-pages.e2e.ts (1)
759-784: Excellent E2E test coverage for past booking restrictions.The test comprehensively verifies that both the cancel button and the "Need to make a change?" text are properly hidden for past bookings. The test setup correctly creates a past booking scenario and the assertions ensure the UI behaves as expected according to the PR requirements.
apps/web/modules/bookings/views/bookings-single-view.tsx (3)
817-818: LGTM: Conditional logic correctly prevents past booking cancellationThe updated condition properly restricts reschedule/cancel options for past bookings while preserving the ability to reschedule past bookings when explicitly configured via
eventType.allowReschedulingPastBookings.
843-843: Good UX improvement: Hide "or" separator for past bookingsThis prevents displaying the "or" text when the cancel button is hidden for past bookings, maintaining clean UI consistency.
849-849: Core feature implemented correctly: Cancel button hidden for past bookingsThis change successfully implements the PR objective by preventing the cancel button from appearing for bookings that have already ended, based on the booking's end time.
8545ad1 to
8aadb25
Compare
|
This PR is being marked as stale due to inactivity. |
|
@husniabad pls fix the conflicts |
8aadb25 to
909efa5
Compare
|
Hi @anikdhabal I have fixed the conflicts and updated the PR to fit the latest design, there could be some failed tests but none of them related to my PR |
There was a problem hiding this comment.
Actionable comments posted: 1
🧹 Nitpick comments (1)
apps/web/components/booking/BookingListItem.tsx (1)
272-288: Initialize edit-actions handlers after hook declarations to avoid TDZ surprisesThese onClick handlers reference state setters declared later (Lines 305-309). While closures make this work at runtime, it’s easy to trip eslint “no-use-before-define” and it’s less readable.
Consider moving this block below the useState declarations (Lines 305-309), or memoize it after those hooks:
// After lines 309 (state hooks) const editEventActions: ActionType[] = getEditEventActions(actionContext).map((action) => ({ ...action, onClick: action.id === "reschedule_request" ? () => setIsOpenRescheduleDialog(true) : action.id === "reroute" ? () => setRerouteDialogIsOpen(true) : action.id === "change_location" ? () => setIsOpenLocationDialog(true) : action.id === "add_members" ? () => setIsOpenAddGuestsDialog(true) : action.id === "reassign" ? () => setIsOpenReassignDialog(true) : undefined, }));
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
Plan: Pro
📒 Files selected for processing (2)
apps/web/components/booking/BookingListItem.tsx(2 hunks)apps/web/components/booking/bookingActions.ts(1 hunks)
🚧 Files skipped from review as they are similar to previous changes (1)
- apps/web/components/booking/bookingActions.ts
🧰 Additional context used
📓 Path-based instructions (2)
**/*.tsx
📄 CodeRabbit Inference Engine (.cursor/rules/review.mdc)
Always use
t()for text localization in frontend code; direct text embedding should trigger a warning
Files:
apps/web/components/booking/BookingListItem.tsx
**/*.{ts,tsx}
📄 CodeRabbit Inference Engine (.cursor/rules/review.mdc)
Flag excessive Day.js use in performance-critical code; prefer native Date or Day.js
.utc()in hot paths like loops
Files:
apps/web/components/booking/BookingListItem.tsx
🧬 Code Graph Analysis (1)
apps/web/components/booking/BookingListItem.tsx (2)
apps/web/components/booking/bookingActions.ts (1)
getEditEventActions(98-162)packages/ui/components/dropdown/Dropdown.tsx (1)
DropdownItem(161-181)
⏰ Context from checks skipped due to timeout of 90000ms. You can increase the timeout in your CodeRabbit configuration to a maximum of 15 minutes (900000ms). (2)
- GitHub Check: Install dependencies / Yarn install & cache
- GitHub Check: Codacy Static Code Analysis
| {cancelEventAction.disabled && isBookingInPast ? ( | ||
| <Tooltip content={t("cannot_cancel_booking")}> | ||
| <div className="w-full"> | ||
| <DropdownItem | ||
| type="button" | ||
| color={cancelEventAction.color} | ||
| StartIcon={cancelEventAction.icon} | ||
| disabled={true} | ||
| data-bookingid={cancelEventAction.bookingId} | ||
| data-testid={cancelEventAction.id} | ||
| className="text-muted cursor-not-allowed" | ||
| onClick={(e) => e.preventDefault()}> | ||
| {cancelEventAction.label} | ||
| </DropdownItem> | ||
| </div> | ||
| </Tooltip> | ||
| ) : ( | ||
| <DropdownItem | ||
| type="button" | ||
| color={cancelEventAction.color} | ||
| StartIcon={cancelEventAction.icon} | ||
| href={cancelEventAction.href} | ||
| onClick={cancelEventAction.onClick} | ||
| disabled={cancelEventAction.disabled} | ||
| data-bookingid={cancelEventAction.bookingId} | ||
| data-testid={cancelEventAction.id} | ||
| className={cancelEventAction.disabled ? "text-muted" : undefined}> | ||
| {cancelEventAction.label} | ||
| </DropdownItem> | ||
| )} |
There was a problem hiding this comment.
💡 Verification agent
🧩 Analysis chain
Make the “disabled cancel” tooltip accessible and reliable (avoid disabling the Radix MenuItem when showing tooltip)
With DropdownMenuItem disabled, Radix prevents focus/selection, and tooltips may not fire on hover/focus. Also keyboard users won’t discover the reason. Keep the MenuItem interactive when showing the tooltip and use aria-disabled on the inner control, preventing selection manually.
Apply the following within this block to keep tooltip + keyboard accessibility:
- {cancelEventAction.disabled && isBookingInPast ? (
+ {cancelEventAction.disabled && isBookingInPast ? (
<Tooltip content={t("cannot_cancel_booking")}>
<div className="w-full">
<DropdownItem
type="button"
color={cancelEventAction.color}
StartIcon={cancelEventAction.icon}
- disabled={true}
+ aria-disabled="true"
data-bookingid={cancelEventAction.bookingId}
data-testid={cancelEventAction.id}
- className="text-muted cursor-not-allowed"
- onClick={(e) => e.preventDefault()}>
+ className="text-muted cursor-not-allowed"
+ onClick={(e) => {
+ e.preventDefault();
+ e.stopPropagation();
+ }}>
{cancelEventAction.label}
</DropdownItem>
</div>
</Tooltip>
) : (Additionally, adjust the wrapper item so it stays focusable when showing the tooltip (outside the selected lines):
// On the DropdownMenuItem wrapper (line 689)
<DropdownMenuItem
className="rounded-lg"
key={cancelEventAction.id}
disabled={cancelEventAction.disabled && !isBookingInPast}
onSelect={
cancelEventAction.disabled && isBookingInPast
? (e) => e.preventDefault()
: undefined
}
>This preserves pointer/keyboard interactions for the tooltip, prevents activation, and improves a11y (screen reader semantics via aria-disabled).
To ensure behavior is consistent across all cancel entry points, verify getCancelEventAction disables past-booking cancellation:
🏁 Script executed:
#!/bin/bash
# Inspect cancel action logic to confirm it disables when isBookingInPast
rg -n "function getCancelEventAction|getCancelEventAction\s*\(" -A 60 apps/web/components/booking
rg -n "isBookingInPast" apps/web/components/booking/bookingActions.ts -A 40Length of output: 25030
To confirm the wrapper behavior, please verify the <DropdownMenuItem> props around where cancelEventAction is rendered:
🏁 Script executed:
#!/bin/bash
# Show the DropdownMenuItem wrapper around cancelEventAction
rg -n "cancelEventAction" -n -A5 -B5 apps/web/components/booking/BookingListItem.tsx | rg -m1 "DropdownMenuItem"Length of output: 156
Please show more context around where cancelEventAction is rendered so we can inspect the wrapping <DropdownMenuItem> props:
🏁 Script executed:
#!/bin/bash
# Display ~20 lines around cancelEventAction for wrapper inspection
rg -n "cancelEventAction" -A20 -B20 apps/web/components/booking/BookingListItem.tsxLength of output: 5744
Refactor Cancel MenuItem to preserve tooltip accessibility
Keep the menu item focusable when showing the “cannot cancel” tooltip and move the actual disabling into the inner control:
• In apps/web/components/booking/BookingListItem.tsx (at the <DropdownMenuItem> wrapper, line 688):
<DropdownMenuItem
className="rounded-lg"
key={cancelEventAction.id}
- disabled={cancelEventAction.disabled}
+ disabled={cancelEventAction.disabled && !isBookingInPast}
+ onSelect={
+ cancelEventAction.disabled && isBookingInPast
+ ? e => e.preventDefault()
+ : undefined
+ }
>• Inside that block (lines 690–703), update the inner <DropdownItem> under the tooltip:
<Tooltip content={t("cannot_cancel_booking")}>
<div className="w-full">
<DropdownItem
type="button"
color={cancelEventAction.color}
StartIcon={cancelEventAction.icon}
- disabled={true}
+ aria-disabled="true"
data-bookingid={cancelEventAction.bookingId}
data-testid={cancelEventAction.id}
- className="text-muted cursor-not-allowed"
- onClick={(e) => e.preventDefault()}>
+ className="text-muted cursor-not-allowed"
+ onClick={e => {
+ e.preventDefault();
+ e.stopPropagation();
+ }}>
{cancelEventAction.label}
</DropdownItem>
</div>
</Tooltip>These changes ensure:
- Tooltip fires on hover/focus (menu item remains interactive).
- Keyboard users can tab into the item and hear the “cannot cancel” message.
- Actual cancellation is blocked via
aria-disabledand suppressing click/select events.
Committable suggestion skipped: line range outside the PR's diff.
🤖 Prompt for AI Agents
In apps/web/components/booking/BookingListItem.tsx around lines 688–703, the
cancel menu item is fully disabled which prevents tooltip accessibility; instead
make the menu wrapper stay focusable and interactive so the Tooltip can fire,
but move the "disabled" behavior into the inner control: render the
<DropdownMenuItem>/<div> as focusable (do not set disabled), wrap the inner
<DropdownItem> with aria-disabled={true} when cancelEventAction.disabled &&
isBookingInPast, add role="button" and tabIndex={0} to the wrapper if needed,
and suppress activation by preventing onClick/onKeyDown (ignore Enter/Space) on
the inner control when aria-disabled is true so the action is not performed;
keep styling (text-muted/cursor-not-allowed) and data attributes on the inner
control so keyboard and screen-reader users can focus the item and hear the
tooltip while clicks/selections remain blocked.
| @@ -27,6 +27,7 @@ export default function Bookings(props: { calUsername: string; calEmail: string | |||
| const year = dayjs(booking?.start).year(); | |||
| const day = dayjs(date).format("dddd"); | |||
| const month = dayjs(date).format("MMMM"); | |||
| const isBookingInPast = new Date(booking?.end) < new Date(); | |||
There was a problem hiding this comment.
There is a type error here. Can you please fix that?
E2E results are ready! |
What does this PR do?
This PR prevents users from canceling past bookings by hiding cancel buttons in the UI and adding server-side checks to block API bypass attempts. It keeps the existing cancellation flow and user experience unchanged for valid future bookings.
Visual Demo (For contributors especially)
A visual demonstration is strongly recommended, for both the original and new change (video / image - any one).
Video Demo (if applicable):
Image Demo (if applicable):
Mandatory Tasks (DO NOT REMOVE)
How should this be tested?