feat: minimum notice for events with seats

[balthazur]

What does this PR do?

• Fixes [CAL-4043] Create an alternative minimum notice for joining events with seats. #13556
• Fixes CAL-XXXX (Linear issue number - should be visible at the bottom of the GitHub issue description)

This PR adds a new advanced setting for event types with seats enabled. The goal is to allow a booking with at least one existing attendee to be booked later than the minimumBookingNotice would allow.

Here is short Loom, demonstrating the feature.

The PR essentially does three things:

1. Adds a new setting to eventType with a corresponding database field "seatsMinimumBookingNumber" (optional). The different settings cases are outlined below. To do that, the MinimumBookingNotice component was moved to its own component and made reusable.
2. Makes changes to the logic responsible for generating available slots for a certain time frame, allowing for available slots that fall within the range that minimumBookingNotice would previously filter out. The changes are outlined and commented on in the flowchart below.
3. Adds integration tests for the new feature.

Changes made to slot logic

These were explained to Zomars during our call. Basically, it does not change the getSlot logic.

The changes were to remove a redundant check for minimumBookingNotice at the top of the getAvailableSlots function; otherwise, we would lose all potential slots that would be enabled by the new setting. We then decide if the feature is active and pass minimumBookingNotice = 0 to getSlots, so we get all available slots.

Further down the getAvailableSlots function, there is a previously redundant "safety check" that filters out out-of-bounds slots based on minimumBookingNotice. We extended this check to watch for seatsMinimumBookingNotice and minimumBookingNotice, so in that special case when the setting is active, we will filter out the correct slots at last.

Settings, 3 cases:

1. Default, empty seatsMinimumBookingNotice:
   

2. shorter minimum booking notice for seats with existing booking:
   

3. "invalid case", handled by allowing it because it's not breaking but we arenotifiying the user that I will have no effect. Use case would also be that user changes the default minimumBookingNotice, so the seatsMinimumBookingNotice becomes valid again.
   

This is what seemed the most reasonable to me. Maybe need to be check with product if this solution is fine.

Full Example:

E.g. minimumBookingNotice is 7 days. There is an existing event with only 1 out of 4 seats booked tomorrow, which cannot be booked. By setting the seatsMinimumBookingNotice to e.g. 1 hour., users are displayed the existing booking with 1/4 seats, and can book it up to 1 hour before the event.

Calendar:

Advanced Settings. Info: Hint message was not implemented yet when I took this screenshot.

Limit Settings:

Mandatory Tasks (DO NOT REMOVE)

• 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. Docs Issue
• I have added or modified automated tests that prove my fix is effective or that my feature works (PRs might be rejected if logical changes are not properly tested)

How should this be tested?

• 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

To test in the app:

1. Create an event type with seats.
2. Add a new booking to it for example 3 days in the future
3. Set the minimum booking notice for example to 7 days
4. Then set a minimum booking notice for joining an existing booking (the new settings, in /advanced/seats) e.g. to 1 day
5. Go to the event page. The event with a booking in 3 days should have an available slot, and the next available slots should be available in 7 days (or whatever the minimum booking is).
6. If the minimum booking notice for seats is not set or is larger then the minimum booking notice, it should have no effect, and this should clear from the hint at the input

Tests can be run with:
TZ=UTC yarn test getSchedule.test.ts

[vercel]

@balthazur is attempting to deploy a commit to the cal Team on Vercel.

A member of the Team first needs to authorize it.

[github-actions]

Thank you for following the naming conventions! 🙏 Feel free to join our discord and post your PR link.

[balthazur]

@CarinaWolli done!

There was some auto-formatting happening in 2 files, I think in a pre-commit hook but I am not sure. I marked the files with a comment. Maybe I have something misconfigured locally?

[github-actions]

This PR is being marked as stale due to inactivity.

[CarinaWolli]

Everything looks good to me, just waiting for @emrysal comment to this

[emrysal]

Suggested change

	eventType.seatsMinimumBookingNotice !== null &&
	!isNaN(eventType.seatsMinimumBookingNotice) &&

Possibly for clarity; undefined is used below as `undefined < {minimumBookingNoticeValue} which will always be false, but it's quite unclear this works this way.

[emrysal]

Why not simplify and go for something like this? Untested pseudocode.

const effectiveMinimumBookingNotice = !isNaN(seatsMinimumBookingNotice) && seatsCount > 0 
  ? Math.min(seatsMinimumBookingNotice, minimumBookingNotice) 
  : minimumBookingNotice;

@CarinaWolli and I also had a discussion just now that may be simplifying further also; we see no reason to continue applying a minimum booking notice once a booking has been booked for further seats. So the seatsMinimumBookingNotice is possibly default-able to 0

[CarinaWolli]

So the seatsMinimumBookingNotice is possibly default-able to 0

Also in the input field we should default to 0 for seatsMinimumBookingNotice, so it's clear to the user

[github-actions]

This PR is being marked as stale due to inactivity.