Ti Ext Reservation Laravel Package

Getting Started

This is a TastyIgniter extension, not a standalone package — it will not do anything useful outside a TastyIgniter app, and it is normally pulled in as part of the core install rather than required directly.

composer require tastyigniter/ti-ext-reservation
php artisan igniter:up        # runs migrations + publishes extension assets

Then enable it in Admin → System → Extensions (or confirm it's in extensions/ / vendor/ and enabled in the extensions table). First places to look:

1. src/Models/ — Reservation, ReservationStatus, DiningArea, Table(s) and the settings model. This is the real API surface; the README only lists features.
2. src/Http/Controllers/ and src/Components/ — admin CRUD and the front-end booking component. Read the component to see how timeslot selection, lead time and table assignment are actually computed before you build your own form.
3. database/migrations/ — column names and nullability on reservations (notably the location/location_id and telephone columns changed type in 4.0.8).
4. The official docs at tastyigniter.com/docs/extensions/reservation — the repo README is thin, and the issue tracker points at the core TastyIgniter repo, not this one.

First use case: configure one location's settings (time interval, stay time, guest capacity, lead time, cancellation window, auto table assignment) in Admin → Location → Reservation, create one dining area with a couple of tables, then place a booking through the front end and watch the record land in Admin → Reservations. That single loop exercises nearly every moving part: timeslot generation, table allocation, status workflow and the confirmation email.

Implementation Patterns

Programmatic bookings. Create reservations through the Eloquent model rather than raw inserts so status defaults, assignTable()-style allocation and notification hooks fire. Resolve the location settings first — timeslot and capacity logic is per-location, not global:

$settings = $location->getSettings('reservation');   // interval, lead_time, stay_time, capacity, auto_allocate
$reservation = Reservation::create([...]);

Read the availability logic, don't reinvent it. The booking/timeslot code is the part that gets patched most often (max-guests-per-timeslot fix in 2.10.1, fully-booked check performance in 4.1.0, getNextBookableTable return type in 4.1.3). Reuse the existing service/helper for "is this slot free?" rather than writing your own overlap query — yours will drift from upstream and break on the next release.

Status transitions. Treat status changes as a workflow, not a column update: the active status set and the transition order come from the reservation status records. Drive notifications and calendar sync from the status change path, and always pass location context (see Gotchas).

Automations over hard-coded emails. The extension ships automation rules (confirmation, reminder — reminder was added as a preset rule in 4.0.11). Prefer wiring your custom behaviour into the automation system / model events over subclassing the mailer; you get retries, per-location recipients and admin visibility for free, and upgrades stay clean.

Multi-location filtering. Since 4.1.4, status updates and calendar syncs are location-scoped. Build a single helper such as updateStatusForLocation($reservation, $status, $location) and route every admin action, console command and queue job through it. Never call updateStatus() from a loop over "all reservations" — that's exactly the implicit-global pattern the release tightened up.

Front-end integration. Extend the booking component's views rather than replacing them (author/extension view overrides), and keep custom fields as a separate table keyed to reservation_id — adding columns to reservations is the fastest way to collide with a future migration.

Reporting. Eager-load relationships on any list you render (4.1.1 added eager loading for this reason). Filter reports by location + date range using the date-time filter helper, which as of 4.2.0 accepts separate startAt/endAt arguments as well as a range array.

Gotchas and Tips

• Location context is now mandatory-ish. Omitting a location on updateStatus / calendar sync can silently no-op or scope wider than you expect. Treat a null/missing location as a bug in your code, and log the resolved location in the command that performs batch updates.
• Settings are cached. After changing reservation settings programmatically, clear the cache or the old interval/lead time keeps being used. This burns hours if you don't know it.
• Lead time and interval interact. start time + lead time vs. plain start time is a per-location setting (added in 2.7.0). Timeslot lists will look "wrong" in staging when the two settings disagree with your test clock — check timezone and this flag before debugging the generator.
• Auto table assignment default flipped to 1 in 4.1.1. If you upgraded and tables are suddenly being assigned to bookings that used to stay unassigned, that's the setting, not a regression.
• Datatable quirks. table_name was made searchable = false in 4.1.1 to avoid a query error; if you add your own columns to the reservations list, copy that pattern for anything joined or aliased.
• Migration name length. 4.0.9 had to rename indexes because MySQL's identifier limit was hit. Name your own indexes short.
• telephone is a string now (4.0.8). Anything doing numeric assumptions on phone numbers will break.
• Version pin the extension against your TastyIgniter core. Releases carry hard core requirements (e.g. 2.10.0 needed v3.6.7+). Check the release note before bumping — composer.json constraints in the extension are the source of truth.
• Debugging path: Laravel query log / Telescope for the scoped-status queries, then the admin calendar sync, then the automation log. Most "reservation didn't update" reports come down to a missing location scope or a cached setting, in that order.
• Extension points: custom reservation statuses (data, not code), automation rules, view overrides, and model observers on Reservation. Avoid forking the model — the 4.1.x line refactored it repeatedly and your fork will rot.
• Where to report bugs: the core TastyIgniter issue tracker, since this repo's README redirects there. Grep the core tracker before assuming a bug is local.