## What does this PR do?
<!-- Please include a summary of the change and which issue is fixed. Please also include relevant motivation and context. List any dependencies that are required for this change. -->
In anticipation of refactoring `handleSeats` we need to abstract `createBooking` in order to get the return type. This PR is purposely aiming to do one thing so nothing is missed while refactoring `handleNewBooking`
Fixes # (issue)
<!-- Please provide a loom video for visual changes to speed up reviews
Loom Video: https://www.loom.com/
-->
## Requirement/Documentation
<!-- Please provide all documents that are important to understand the reason of that PR. -->
- If there is a requirement document, please, share it here.
- If there is ab UI/UX design document, please, share it here.
## Type of change
<!-- Please delete bullets that are not relevant. -->
- [x] Chore (refactoring code, technical debt, workflow improvements)
## How should this be tested?
<!-- Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration. Write details that help to start the tests -->
- Are there environment variables that should be set?
- What are the minimal test data to have?
- What is expected (happy path) to have (input and output)?
- Any other important info that could help to test that PR
## Mandatory Tasks
- [ ] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.
## Checklist
<!-- Please remove all the irrelevant bullets to your PR -->
- I haven't read the [contributing guide](https://github.com/calcom/cal.com/blob/main/CONTRIBUTING.md)
- My code doesn't follow the style guidelines of this project
- I haven't commented my code, particularly in hard-to-understand areas
- I haven't checked if my PR needs changes to the documentation
- I haven't checked if my changes generate no new warnings
- I haven't added tests that prove my fix is effective or that my feature works
- I haven't checked if new and existing unit tests pass locally with my changes
* feat: Base implementation of v2 of avatars
* Make avatarUrl and logoUrl entirely optional
* Made necessary backwards compat changes
* fix: type errors
* Fix: OG image
* fix types
* Consistency with other behaviour, ux tweak
---------
Co-authored-by: Peer Richelsen <peeroke@gmail.com>
* Inital UI + layout setup
* use booker approach of grid
* event-select - sidebar + store work
* adds get schedule by event-type-slug
* Calendar toggle
* Load schedule from event slug
* Add busy events to calendar
* useschedule
* Store more event info than just slug
* Add date override to calendar
* Changes sizes on smaller screens
* add event title as a tooltip
* Ensure header navigation works
* Stop navigator throwing errors on inital render
* Correct br
* Event duration fixes
* Add getMoreInfo if user is authed with current request.username
* Add calendar color map wip
* Add WIP comments for coloured outlines
* Revert more info changes
* Calculate date override correctly
* Add description option
* Fix inital schedule data not being populated
* Nudge overlap over to make it clearer
* Fix disabled state
* WIP on math logic
* Event list overlapping events logic
* NIT about width
* i18n + manage calendars link
* Delete old troubleshooter
* Update packages/features/calendars/weeklyview/components/event/EventList.tsx
* Remove t-slots
* Fix i18n & install calendar action
* sm:imrovments
* NITS
* Fix types
* fix: back button
* Month prop null as we control from query param
* Add head SEO
* Fix headseo import
* Fix date override tests
Fixes: https://github.com/calcom/cal.com/issues/12297
Fixes https://github.com/calcom/cal.com/issues/11234
- Displaying error message and X-Vercel-Id( Unique Request Id ) to user on book event form
- Improve error logging
- Add Error codes
Few things to discuss
1) How to handle calendar integration failures ?
Currently if for example google integration is broken and someone is trying to book that person then we log the error but don't inform the user that the google calendar is broken and the meeting goes through.
Should I throw error when integration is broken ?
<img width="758" alt="Screenshot 2023-11-12 at 12 52 36 AM" src="https://github.com/calcom/cal.com/assets/53316345/c4d921c4-9c8a-4b9b-82a2-bbe0fdbcb3d4">
2) How to handle conferencing app failures?
We just default to Cal Video as location if we are unable to generated conferencing url and log the error and not inform the user(organizer).
## What does this PR do?
Fixes that it can happen that Round Robin host is booked outside of availability.
I found and fixed the following two scenarios where this can happen:
- when host has a date override
- when host is available for only a part the event time (for example, booking time 9:00-11:00 and user is only available between 10:00-11:00)
Fixes#10315Fixes#11690
It also fixes that it can happen that round robin doesn't correctly pick the luck user (least recently booked). This happened when a user was an attendee of a booking before, then we always compared this booking and never the actual last booking of this user.
## Type of change
- [x] Bug fix (non-breaking change which fixes an issue)
## How should this be tested?
#### Booked outside of availability:
1.
- Create Round Robin event and assign user1 and user2 as round robin hosts
- event duration: 120 minutes
- user 1 availability:
- Monday to Friday 9:00-17:00
- user2 availability:
- Monday to Friday 10:00-17:00
- Book event at a 9:00 slot -> check if i user1 is booked
- Book event again at a 9:00 slot -> check if user1 is booked again (user2 is not available at that time)
2.
- Change availability of user2
- Mark Monday as unavailable
- Add date override on any day this month
- Book any Monday this month -> see that user 1 is booked
- Again Book any Monday this month -> see that user 1 is booked again
#### Wrong lucky user
- Book event and add user1's email as the attendee email address
- Book several slots where both users should be available, and see that it alternates between user1 and user2 (before it ended up always booking user1)
## Mandatory Tasks
- [ ] Make sure you have self-reviewed the code. A decent size PR without self-review might be rejected.
