Rezervace

Životní cyklus rezervací

1. Otevření rezervace na event
2. Vytvoření rezervace
   1. Automatické ověření volné kapacity
   2. Přiřazení stolu (pokud má podnik nakonfigurované stoly)
   3. Uložení rezervace
   4. Aktivace autorezervace – pokud byla zaškrtnuta
3. Odeslání emailu s potvrzením rezervace a možností storna

Scénáře chování

1. Kapacita podniku je vyčerpána

Hráč může i tak zaregistrovat svůj tým, ale automaticky proběhne rezervace v režimu overbookingu – tým se uloží jako náhradník (AlternateReservation).
Pokud dojde ke zrušení rezervace jiného týmu, automaticky odejde email s informací o uvolnění kapacity všem náhradním týmům.
Obsazení volného místa je v režimu „Kdo dřív přijde, ten dřív mele.”

2. Vytvoření rezervace s autorezervací

Pokud při zakládání rezervace zároveň zaškrtnu autorezervaci, pak se mi automaticky vytvoří rezervace na další termín neprodleně po dokončení aktuálního eventu.
Pokud další termín vyhlášen není, rezervace proběhne až v momentě ručního vytvoření eventu pro daný předpis, případně při automatickém vygenerování eventu. Tato kontrola probíhá denně v 9:00.

3. Zrušení autorezervace

Zrušením autorezervace automaticky rušíme i rezervace na konkrétní eventy v budoucím čase. Pokud jsem tedy např. v pondělí udělal rezervaci s autorezervací na čtvrtek a autorezervaci v úterý zruším, dojde i ke zrušení rezervace na tento čtvrteční event.
Zrušení je hráči potvrzeno emailem včetně informace o zrušení rezervace na event, pokud existuje.

4. Automatické zrušení autorezervace po opakovaném nepotvrzení

Autorezervace (StandingReservation) generuje pro každý nový event TeamReservation, která čeká na potvrzení od týmu. Pokud tým opakovaně nepotvrdí:

• Po každém nepotvrzení se inkrementuje počítač consecutive_unconfirmed_count
• Potvrzení rezervace counter resetuje na 0
• Jakmile dosáhne 3 po sobě jdoucích nepotvrzených rezervací, autorezervace se automaticky trvale zruší a tým dostane email StandingReservationCancelledPermanent

---

Systém kapacit

Kapacita eventu se počítá dvěma způsoby podle toho, jak má podnik nakonfigurované stoly.

Nový systém – PubTables

Pokud má podnik nakonfigurované konkrétní stoly (PubTable), kapacita = počet volných stolů.
Každý tým dostane při rezervaci automaticky přiřazený konkrétní stůl:

1. Hledá se stůl kde optimal_capacity >= počet hráčů
2. Pokud takový neexistuje, hledá se stůl kde max_capacity >= počet hráčů (přeplnění stolu s potvrzením)
3. Stůl se přiřadí do pub_table_id na rezervaci

Legacy systém – capacity pole

Pokud podnik nemá PubTables, kapacita se počítá ze součtu hodnot v JSON poli capacity (velké + malé stoly).
Kapacita = počet zbývajících míst (součet capacity minus počet rezervací).
Týmy v legacy systému nemají přiřazený konkrétní stůl (pub_table_id = NULL).

Hierarchie layoutu

Při výpočtu kapacity a přiřazování stolů se prochází tato hierarchie:

1. Event – má vlastní specifický layout (TableLayoutItem)
2. Blueprint – layout sdílený všemi eventy předpisu
3. Podnik – výchozí stoly podniku (PubTable)

Přechod z legacy na nový systém

Při nasazení migrace se pro podniky s legacy capacity polem automaticky vygenerují PubTables:

• capacity.seats → stoly s optimal_capacity = 6, max_capacity = 8
• capacity.smallseats → stoly s optimal_capacity = 2, max_capacity = 4

Stávající rezervace zůstanou bez přiřazeného stolu (pub_table_id = NULL) a fungují v legacy módu.

---

Práce s rezervacemi

Záložka rezervace – admin

Správa rezervací v administraci, přehled všech rezervací pro daný event.

Panel moderátora

Moderátor vidí přehled rezervací ke svým eventům. U autorezervací lze manuálně přiřadit konkrétní stůl přes StandingReservationsTable.

Správa rezervací a autorezervací z pohledu hráče – web

Hráč může spravovat své rezervace a autorezervace přes tokenový odkaz v emailu.

---

Developer notes

TeamReservation

• Má vlastní observer (ReservationObserver)
• Observer na základě sledování změn odesílá vhodné notifikace a spouští sekundární procesy:
  • Notifikace: vytvoření, zrušení, uvolnění místa, potvrzení z uvolněného místa
  • Job: InviteAlternateReservations – email o uvolněném místě náhradním týmům
• pub_table_id – přiřazený stůl (nullable, nullOnDelete)
• standing_reservation_id – odkaz na nadřazenou autorezervaci (nullable)
• confirmed_at – čas potvrzení standing rezervace hráčem
• Metoda confirm() – potvrdí rezervaci a resetuje consecutive_unconfirmed_count na autorezervaci
• Metoda cancelUnconfirmed() – zruší nepotvrzenou rezervaci a inkrementuje consecutive_unconfirmed_count

StandingReservation

• Má vlastní observer
• Observer odesílá notifikace: vytvoření, potvrzení zrušení autorezervace
• Job: EnsureExactlyOneFutureTeamReservationJob – firstOrCreate funkce pro rezervaci na právě jeden následující event
• pub_table_id – preferovaný stůl (nullable), přenáší se na generovanou TeamReservation
• consecutive_unconfirmed_count – počítač nepotvrzených rezervací; při dosažení 3 se autorezervace automaticky smaže

AlternateReservation

• Samostatná tabulka (od migrace 2026_03_23_150010), dříve příznak is_alternate=1 na TeamReservation
• Tým čeká ve frontě bez přiřazeného stolu
• Při uvolnění místa se promuje na TeamReservation se stolem

PubTable

• Model app/Models/PubTable.php
• Pole: pub_id, note, optimal_capacity, max_capacity, sort_order, is_active
• Soft deletes – při smazání stolu se pub_table_id na rezervacích nastaví na NULL
• Správa přes Livewire komponentu PubTableManager