Volleyball Elite Academy development update

Volleyball Elite Academy Rental court capacity Rental court capacity Volleyball Elite Academy — Development Update • May 16, 2026 --- title: Let multi-court rentals run several events at the same time without false 'not enough time' errors --- Rental court capacity What & Why Today the rental capacity check treats every gym rental as a single shared time pool, so two events booked on the same Beach-Full or indoor-soccer rental at the same wall-clock time falsely trip the "Not enough time on rental" error — even though the facility physically has multiple courts that can run in parallel. SuperAdmins should be able to record how many courts a rental covers (e.g. 1 for most school gyms, 3 for the indoor soccer courts, 4 for the beach courts) so the validator allows up to that many concurrent events instead of summing all minutes against a single-court window. Done looks like The gym rental admin form has a "Number of courts" field that defaults to 1, accepts whole numbers ≥ 1, and is shown on the rentals list/detail. Existing rentals continue to behave exactly as today (court count = 1) until an admin edits them. When a rental's court count is set to N, the preflight validator and the per-date assign route both allow up to N × the rental window of total booked minutes across all events linked to that rental, instead of just 1× today. Re-running the scenario in the screenshot (Beach-Full 5:00 PM–6:55 PM with court count = 4 and another 60-minute event already on it) lets the new 120-minute date save without the "Not enough time on rental" error. The rentals list view's "remaining minutes" / "used slots" math reflects the new multi-court capacity so admins see an accurate picture. The error message, when it does fire, names the court count so it's obvious why capacity was exceeded (e.g. "115 min × 3 courts = 345 min available, 400 min requested"). Out of scope Reconciling the separate issue that events are written as ending at 7:00 PM while the rental ends at 6:55 PM. That 5-minute mismatch is a real bug but is a different fix (either tolerate a small buffer or align how rentals are recorded) and should be its own task once we decide which direction to go. Per-court assignment (i.e. tagging each event date with which of the N courts it uses). The validator will only enforce concurrency count, not specific court identity. Facility-level defaults (e.g. "every rental at this address inherits court count 4"). Court count lives on the rental row directly; admins set it per rental. We can layer a facility default on later if it becomes painful. Backfilling existing rentals to anything other than 1 court — admins will update the multi-court ones manually after this ships. Steps 1. Schema + storage — Add a integer column to (default 1, not null, check ≥ 1), surface it through the insert/select Zod schemas, and update so reads/writes carry the field. 2. Capacity math — Update so the available capacity is , and refresh the overbooked message + the structured error fields so the rental's court count is included. Keep the single source of truth shared between the preflight endpoint and the per-date route. 3. Rentals list view — Update (and any frontend that consumes it) so , , and reflect court count, and show court count in the list/detail UI. 4. Admin form — Add the "Number of courts" input to the gym rental create/edit form with a default of 1, min 1, integer-only validation; wire it through the form schema, mutation, and any optimistic cache updates. 5. Tests — Extend , , , and to cover: court count defaulting to 1 keeps existing behaviour; court count = N allows up to N concurrent bookings of the full window; overbooking past N × window still errors with the new message that names the court count. Relevant files - - - - - - - - - - Volleyball Elite Academy Reply to this email — we read every reply. You received this because you have an account with Volleyball Elite Academy. elitevolleyball.training