fix: persist requiresCancellationReason selection

[Maheshkumarjena]

What does this PR do?

• Fixes Require cancellation reason setting doesn't save #29263

This PR fixes an event type settings persistence issue for Require cancellation reason on the event type edit page.

When a host selected Mandatory for attendee only and saved the event, the value was not being rehydrated correctly after refresh/reopen. The saved setting existed, but the Advanced Settings UI fell back to the default Mandatory for host only.

This PR is intentionally scoped only to the dropdown persistence issue. It ensures the saved requiresCancellationReason value is:

• returned in the event type edit fetch path
• included in the event type form defaults
• shown correctly in the Advanced tab after refresh/reopen

It also adds a regression test covering the event type fetch path for requiresCancellationReason.

Video Demo

1. Before fix

before.fix.mp4

Shows:

• Open Event Type → Advanced
• Select Mandatory for attendee only
• Save the event
• Refresh or reopen the event
• UI incorrectly shows Mandatory for host only

2. After fix

ff1.mp4

Shows:

• Open Event Type → Advanced
• Select Mandatory for attendee only
• Save the event
• Refresh or reopen the event
• UI correctly continues to show the saved option

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 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?

• No special environment variables are required beyond the normal local setup for editing event types.
• Minimal test data:
  • 1 user account
  • 1 event type owned by that user

Test steps:

1. Open an event type.
2. Go to Advanced.
3. Under Require cancellation reason, select Mandatory for attendee only or any other options.
4. Save the event type.
5. Refresh the page or leave and reopen the same event type.
6. Confirm the dropdown still shows Mandatory for attendee only or any other choosen option that persists after refresh .

Expected result:

• The selected dropdown option persists after save and reload.
• The UI matches the saved backend value instead of falling back to the default option.

Automated coverage:

• Added a regression test for the event type fetch path to ensure requiresCancellationReason is returned when configured.

Checklist

• I have read the contributing guide
• My code follows the style guidelines of this project
• I have checked that my changes generate no new warnings relevant to this fix
• My PR is small and focused

[github-actions]

Welcome to Cal.diy, @Maheshkumarjena! Thanks for opening this pull request.

A few things to keep in mind:

• This is Cal.diy, not Cal.com. Cal.diy is a community-driven, fully open-source fork of Cal.com licensed under MIT. Your changes here will be part of Cal.diy — they will not be deployed to the Cal.com production app.
• Please review our Contributing Guidelines if you haven't already.
• Make sure your PR title follows the Conventional Commits format.

A maintainer will review your PR soon. Thanks for contributing!

[coderabbitai]

📝 Walkthrough

Walkthrough

This PR exposes the requiresCancellationReason field through the event-type form by establishing a type contract in FormValues, ensuring the repository queries fetch the field, wiring it into form initialization with useEventTypeForm, and rendering it in the EventAdvancedTab component with appropriate defaults. Integration tests validate that the field flows correctly from database creation through the data access layer.

🚥 Pre-merge checks | ✅ 5

✅ Passed checks (5 passed)

Check name	Status	Explanation
Description check	✅ Passed	The description clearly explains the bug being fixed, the scope of changes, and includes test instructions and demo videos demonstrating the issue and fix.
Linked Issues check	✅ Passed	The PR directly addresses issue #29263 by ensuring requiresCancellationReason is returned from the fetch endpoint, included in form defaults, and displayed correctly after refresh.
Out of Scope Changes check	✅ Passed	All changes are scoped to the dropdown persistence issue: form type definitions, repository queries, form hooks, and a regression test.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Title check	✅ Passed	The title 'fix: persist requiresCancellationReason selection' accurately describes the main change: ensuring the requiresCancellationReason setting persists across form reloads by adding it to form defaults, repository queries, and type definitions.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with 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.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[github-actions]

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.

[Maheshkumarjena]

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 @romitg2 , this PR was marked stale due to inactivity. Whenever you get a chance, could you please review it? I’d appreciate any feedback or requested changes. Thank you!

[github-actions]

Hey there and thank you for opening this pull request! 👋🏼

We require pull request titles to follow the Conventional Commits specification and it looks like your proposed title needs to be adjusted.

Details:

No release type found in pull request title "fix : persist requiresCancellationReason selection". Add a prefix to indicate what kind of release this pull request corresponds to. For reference, see https://www.conventionalcommits.org/

Available types:
 - feat: A new feature
 - fix: A bug fix
 - docs: Documentation only changes
 - style: Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc)
 - refactor: A code change that neither fixes a bug nor adds a feature
 - perf: A code change that improves performance
 - test: Adding missing tests or correcting existing tests
 - build: Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm)
 - ci: Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs)
 - chore: Other changes that don't modify src or test files
 - revert: Reverts a previous commit

[github-actions]

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.

[bandhan-majumder]

@Maheshkumarjena can u also include the cancellation too in the demo showing the where it is required and where not? Once added, please open the PR again.

[Maheshkumarjena]

Hi @bandhan-majumder ! I've attached the demo video to show the cancellation flow functionality , demonstrating both cases where a cancellation reason is required and where it is not required based on the selected setting.

below are the video and screenshot. Please let me know if there's anything else you'd like me to include.

cancellation.reason.functional.mp4

Thanks!

[bandhan-majumder]

Awesome @Maheshkumarjena . Tested locally, works fine. Approving!

[Maheshkumarjena]

Awesome @Maheshkumarjena . Tested locally, works fine. Approving!

Thank you for the review and for helping get this merged. I appreciate it.

[Maheshkumarjena]

Hi @bandhan-majumder ,

When you have a chance, could you please take a look at #29493 ?

It fixes #28986 and addresses a significant issue affecting customers using Office365 integrations. As mentioned by Aroman , attendees can receive misleading Outlook cancellation emails for seated bookings, which can cause confusion.

I've added the fix along with tests and would appreciate your review whenever you're available. Thanks!