What does this PR do?

This change adds the ability for users to permanently remove past bookings from their calendar history. Here’s what it does:

What users can now do:

• Delete past bookings in accordance with their privacy obligations
• Clean up their booking history by removing old appointments they no longer need to keep

Who can delete what:

• For personal bookings: Only the person who owns the booking can delete it
• For team bookings: Only team owners and administrators can delete any team booking. Regular team members cannot delete team bookings.

Safety measures included:

• Only past bookings can be deleted - you can’t accidentally delete upcoming appointments
• A confirmation dialog appears before deletion to prevent mistakes
• Proper error handling if something goes wrong during deletion
• The feature respects existing team permissions and user roles

Technical implementation:

• Adds a new “Delete” option to the booking actions menu for eligible past bookings
• Creates a clean confirmation dialog before proceeding
• NOTE: This is a HARD delete
• Includes test coverage to ensure reliability
• Updates the database seed data to include sample past bookings for testing

This gives users more control over their booking history, particularly to help with meeting privacy obligations.

For this initial version of the feature, bookings may be deleted individually (e.g., there’s no option to select multiple past bookings or to delete all past bookings that match some criteria).

• Fixes #18787
• Fixes CAL-5114

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):

https://github.com/user-attachments/assets/40899b9d-5315-4e30-b092-512ee9e465b9

Image Demo (if applicable):

• Add side-by-side screenshots of the original and updated change.
• Highlight any significant change(s).

Before	After

Mandatory Tasks (DO NOT REMOVE)

• I have self-reviewed the code (A decent size PR without self-review might be rejected).
• I have updated the developer docs in /docs if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox. N/A
• I confirm automated tests are in place that prove my fix is effective or that my feature works.

How should this be tested?

Tested by adding past bookings to seed, then logged in as different users (with varying permissions) to verify users with appropriate permissions could delete past bookings.

Are there environment variables that should be set?

• No, not required.

What are the minimal test data to have?

• A user account (personal bookings scenario)
• A team with admin/owner role assignment (team bookings scenario)
• At least one completed/past booking for personal testing
• At least one completed/past team booking for team testing
• The updated seed data includes these automatically when running yarn db:seed

What is expected (happy path) to have (input and output)?

Input:

• User with appropriate permissions (booking owner for personal bookings, or team admin/owner for team bookings)
• A past booking (endTime < current time) visible in the bookings list
• Click on the booking’s action menu and select “Delete”
• Confirm deletion in the dialog

Output:

• Success toast: “Booking deleted successfully”
• Booking disappears from the bookings list
• Database record is permanently removed
• Bookings list refreshes automatically

Any other important info that could help to test that PR

Testing scenarios:

• Personal Booking Deletion: Log in as a user, find a past personal booking, delete it
• Team Booking Deletion: Log in as team admin/owner, find a past team booking, delete it
• Permission Checks: Try deleting as a regular team member (should not be able to see the delete button, and if you manage to send the request, it will fail)
• Time Validation: Try deleting an upcoming booking (should not show delete option)
• Error Handling: Test with invalid booking IDs or network issues

Test data setup:

• Run yarn db:seed to populate test bookings automatically
• The seed creates past bookings for both personal and team scenarios

Key behaviors to verify:

• Delete button only appears for past bookings, and to users who can delete
• Confirmation dialog prevents accidental deletion
• Proper error messages for insufficient permissions
• Toast notifications work correctly
• List refreshes after successful deletion

Browser testing:

• Test the confirmation dialog UI/UX
• Ensure proper loading states during deletion
• Verify responsive design on mobile devices

Checklist

Future development notes

I saw some comments about bulk deleting. I chose not to incorporate that into these changes yet (since the approach to user flow should be discussed prior). In the meantime, here are some general thoughts I noted down while brainstorming:

• Bulk delete functionality (select many, then delete) could be incorporated by adding a route & schema, adding bulk handler logic (e.g., reuse existing logic to loop through each booking ID to validate permission individually, process deletions in db transaction for atomicity, handle partial failures, …), and adding the option to the frontend flow.
• In context of privacy obligations, it may make more sense to bulk delete past bookings where attendee email equals some value. In that case, the handler logic would find all past bookings with matching attendee, filter to only bookings the user can delete, return list for confirmation, and execute bulk deletion with db transaction.

/claim #18787

Summary by cubic

Added the ability for users to permanently delete past bookings from their calendar history. Only booking owners (for personal bookings) or team admins/owners (for team bookings) can delete, and only for bookings that have already ended.

• New Features
  • “Delete” option appears for eligible past bookings.
  • Confirmation dialog prevents accidental deletion.
  • Proper permission checks and error handling.
  • Test coverage and updated seed data for testing.