Enables multiple barbers/staff bookable at the same location and time
-- previously "resource" conflated "location" and "the thing that
can't double-book itself" into one row, so a Filiale could only ever
have exactly one bookable slot at once.
- New `locations` table; `resources.location_id` with a generic,
idempotent backfill migration (any resource without a location gets
one auto-created matching its name -- not a one-off for any single
client, protects any future resource stuck in the old flat shape too)
- `resources`/`resource_hours`/services keep everything they already
had (hours, min-notice, max-advance, buffer, the no-overlap
constraint) scoped to resource_id, not location_id -- two barbers at
one location must stay independently bookable at the same time
- booking_db.py: new locations CRUD mirroring the existing
resources/services pattern; create_resource now requires a
location_id, guarded the same way every other tenant check here is
(get_location existence check, no real FK -- matches this schema's
existing no-FK convention throughout)
- app.py: new POST /api/locations provisioning route; POST
/api/resources now requires location_id
- owner_settings.py + settings.html: new self-service "add a Filiale"
/ "add a barber" UI -- there was previously no way to create a
resource at all outside the CRM/n8n provisioning API
- public_booking.py + book.html: new Filiale picker (reuses the
existing wireOptionGroup button-group pattern), filtering the
Mitarbeiter picker to the selected location -- a single-location
client sees no extra click, same as before Filialen existed
- owner_booking.py + agenda.html: the Filiale show/hide toggle and
hide-cancelled toggle (shipped earlier this session) now key off
location_id instead of resource_id, so hiding a Filiale hides every
barber's bookings at it; manual-booking dropdown grouped by Filiale
- n8n/onboarding.json: default provisioning now creates a "Hauptfiliale"
location before its resource (inert until re-imported into the live
n8n instance)
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Adds the plumbing every other booking ticket builds on: resources,
services, users, and password_reset_tokens tables, plus the clients
columns (slug, timezone, auto_confirm, ics_token) and the bookings
resource_id/EXCLUDE-constraint double-booking protection described in #14.
booking_db.py is the only place raw SQL runs against these tables --
every function takes client_id and injects the tenant filter itself,
and create/update_booking additionally verify the resource_id belongs
to that client before writing, closing a guessed-ID cross-tenant hole.
Tests spin up a real throwaway Postgres 16 container (matching prod) and
exercise the EXCLUDE constraint, tenancy isolation, and password-reset
single-use semantics end to end, per #14's "real Postgres, no mocking"
testing decision.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
mivanchenko