cal.com
cal.com copied to clipboard
fix: Add check for first slot only restriction in booking API
What does this PR do?
- Fixes #16030
- Fixes CAL-4098
https://www.loom.com/share/70ff42c56724446d9172ac33aa71bf1d?sid=79d948db-6128-4576-9c9e-00881e59f56f
Mandatory Tasks (DO NOT REMOVE)
- [x] I have self-reviewed the code (A decent size PR without self-review might be rejected).
- [ ] I have added a Docs issue here if this PR makes changes that would require a documentation change. If N/A, write N/A here and check the checkbox.
- [ ] I confirm automated tests are in place that prove my fix is effective or that my feature works.
How should this be tested?
Please refer the video above 👆
@Souptik2001 is attempting to deploy a commit to the cal Team on Vercel.
A member of the Team first needs to authorize it.
Graphite Automations
"Add community label" took an action on this PR • (08/02/24)
1 label was added to this PR based on Keith Williams's automation.
"Add consumer team as reviewer" took an action on this PR • (08/02/24)
1 reviewer was added to this PR based on Keith Williams's automation.
"Add foundation team as reviewer" took an action on this PR • (10/09/24)
1 reviewer was added to this PR based on Keith Williams's automation.
I have added quite a few inline comments for better understanding as the logic is a little complex over here. But as pointed out in another PR, if not required let me know I can remove it.
Thanks @anikdhabal . Removed the inline comments you mentioned.
P.S - there are others that I didn't remove, as you didn't mention those.
Need a final review from @CarinaWolli before approving
suggestion: in the best scenario, even if someone tries to edit the URL and tries to enter a different time slot that is not meant to be booked, the page should not render at all. Instead, it should persist with the original time slot.
This PR is being marked as stale due to inactivity.
This PR is being marked as stale due to inactivity.
@anikdhabal Can you please check my intuition here that since we already have this functionality in the web app, there shouldn't need to be this amount of logical changes in the core getUserAvailability call. Instead, the API should just be able to supply whatever params/data needed such that it makes use of the core logic.
Moving back to draft since there are conflicts to fix.
The pr is still incomplete and need to address few things more. Closing it for now