New barber Amarildo Champimpi is introduced on the barber page in all three
languages, and workers can now be restricted to a subset of the services in
their category.
Amarildo cannot perform beard colouring, any waxing, or the all-in package, and
he is a barber only - but category 1 "Kozmetika" holds 19 barber AND 27 beauty
services, so the category-derived vertical wrongly made him beauty-capable.
Because the worker picker is only ever fetched AFTER services are ticked, one
per-service capability filter solves both problems: excluding him from every
beauty service removes him from that vertical entirely.
worker_services(worker_id, service_id) is an allow-list where an EMPTY set means
UNRESTRICTED. That default is deliberate: a missing migration degrades to the
previous behaviour instead of hiding every worker from the booking flow, and
existing workers keep working untouched. Ticking every box in the admin grid
stores nothing at all, so an unrestricted worker also picks up services added
later; unticking even one makes the worker restricted, and new services must
then be granted explicitly.
Enforcement is in three places. The picker offers only workers who can perform
EVERY selected service, and both booking paths re-check server-side, since the
picker is only a UI affordance - a crafted POST now gets service_not_offered/403
rather than a booking the worker cannot honour.
Fixed alongside, all found while building the above:
- getWorkersByCategorySlug() never filtered is_active, so marking a worker
inactive had NO effect on the public booking flow. Both of its callers are
guest-facing. The sibling fallback getActiveWorkers() had always filtered it.
- Worker profile picture uploads failed SILENTLY above PHP's upload_max_filesize.
Both upload blocks gated on tmp_name alone, which cannot distinguish a rejected
upload from "no file chosen" - PHP empties tmp_name in both cases - so the
worker was saved with an empty worker_profile_img and no error shown. The
upload error code is now read and reported, and a separate guard catches
post_max_size overflow, where $_POST and $_FILES both arrive empty and the form
silently did nothing at all.
- createWorker() omitted is_active from its INSERT, so the column default (1)
always won and a worker created as inactive silently came back active.
Migration - the table MUST be created before this code is deployed, because the
picker query subselects it whenever service ids are passed:
CREATE TABLE worker_services (
worker_id INT NOT NULL,
service_id INT NOT NULL,
PRIMARY KEY (worker_id, service_id),
KEY idx_worker_services_worker (worker_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
Already applied on test, dev and prod. Server-side, upload_max_filesize/
post_max_size were raised to 8M/12M on all three environments (php.ini on test,
.user.ini on the shared-host dev and prod docroots) - not carried by this commit.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TYGSbK1erKv7VG1pvdPEjG
An address like "asdf" used to be accepted: the field was type="text" with
only `required`, and there was no server-side check. createBooking() runs
long before sendEmail(), so the failure was silent rather than loud -
reproduced end to end on test:
- the booking row WAS created, with a manage_token
- PHPMailer's addAddress() threw, so nothing was ever sent
- the Location header was already queued, so the guest was redirected to
the normal "booking finished" page and saw success
- Evelin is a CC on that same message, so the salon was not told either
- the guest had no manage link, so they could not cancel
Fixes
- booking_process() rejects an empty or malformed address BEFORE any write,
returning invalid_email / HTTP 400. Message added in all three languages,
worded to say why it matters (the confirmation and the manage link go
there). filter_var is equal-or-stricter than PHPMailer's own validator -
checked against it on ten cases - so anything accepted here cannot throw
later.
- The three public booking forms use type="email", so most typos never
reach the server.
- Removed three debug echoes from User_model::sendEmail() that leaked $lang
and Hungarian strings ("Üzenet elküldve", "Üzenetküldési hiba. Mailer
Error: ...") into the guest-facing response.
Scope
- Public flow only. 508 existing bookings have an empty guest_email because
admin-created block bookings legitimately have none; those go through
Admin::booking_process(), which is untouched, and its form stays
type="text".
- Not covered: a valid address whose SMTP delivery fails still leaves the
booking created and the guest seeing success, logged only via
log_message(). Different failure mode, needs a separate decision.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Introduces /massage alongside barber and beauty: landing page, booking
flow, admin support, home tile and SEO entries, in all three languages.
Architecture
- application/config/verticals.php + vertical_helper.php: one registry
entry per vertical (branding, assets, views, behaviour flags). A fourth
vertical is a config entry plus content files.
- Strangler: barber and beauty keep pointing at their existing view files,
so their rendered HTML is unchanged. Only massage uses the new generic
pages/vertical-*.php and includes/vertical-*.php views, which collapse
the four duplicated per-language nav/footer branches into one.
- Pages::vertical() + one route; booking(), booking_finished(),
_booking_error() and manage_booking() are now registry-driven.
Worker/vertical coupling
- getActiveWorkers() derives the vertical from services.service_category_id
instead of the workers.is_barber / is_beauty flags, which were a
hand-maintained cache of exactly that fact. Verified against production
data: the derived set reproduced the stored flags for every worker, in
both verticals. No schema change was needed for massage.
- The legacy flags are now written through from the category so a rollback
cannot strand a new worker, and the admin worker UI shows the derived
verticals read-only instead of two dropdowns that controlled nothing.
Bug fixes found along the way (all pre-existing)
- booking_process() had no server-side category guard; cross-vertical
mixing was prevented only by client-side JS.
- add-service-form / add-worker-form emitted `selected` on every category
option, so the newest category silently became the default.
- update-service-form offered only barber/beauty, so editing a service of
any other type silently rewrote it.
- getWorkerScheduleByDay ignored schedule overrides while getAvailableTimes
honoured them, so slots could be shown and then rejected. Added an
override-aware getWorkerScheduleForDate() and used it in both guards.
- Booking lists dereferenced a null service if one had been hard-deleted.
- main.css: .tiles was tuned for exactly two tiles, including an
absolutely-positioned .style1 at the 1280px breakpoint.
Massage-specific behaviour, opt-in per vertical
- strip_category_prefix: grouped service lists show "50 min" under the
treatment heading rather than repeating the full name. The full name is
carried in data-service-name so the totals panel stays unambiguous, and
services.service_name is untouched for emails and admin.
- single_service_booking: one treatment per booking, enforced in the UI and
in booking_process(). Re-clicking the selection releases it.
- Displayed treatment time (50/80/110 min) is in the service name; the
booked slot (60/90/120 min) is service_time and covers changing and
payment. service_time is never shown to the guest.
DB migrations for dev/prod are in documents/ - additive only, no ALTER.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Customers intermittently hit a full-screen raw JSON error when booking:
{"error":"Conflict. Timeslot is taken or does not fit the service."}
booking_process() re-validates the chosen slot at submit time and returned
409/403 raw JSON. Because the public booking form is a full-page POST, that
JSON filled the whole screen.
The trigger is a double submit. After inserting the booking, booking_process()
synchronously runs two Google Calendar createEvent calls, a lunch sync, an ntfy
push and an SMTP confirmation e-mail before redirecting - several seconds - and
the submit button was never disabled. On mobile the guest taps "Send" again; the
second request arrives after the first has committed, so the slot reads as taken.
Evidence: 168 duplicate booking pairs exist in prod (same guest, slot and worker,
consecutive booking ids, including runs of four). All are from 2025, none from
2026 - the 409 guard added around May 2025 converted those silent duplicates
into today's visible error.
Prevent the double submit:
- disable the submit button and relabel it on first submit, ignore later ones
- add a hidden sendBooking field, since disabling a submit button can drop its
name/value from the POST and booking_process() bails to the homepage without it
Handle it gracefully when it still happens:
- new _booking_error() renders a localised page in the right skin instead of raw
JSON, replacing all six JSON responses in booking_process()
- new booking-error views for barber/beauty in no/en/hu, each with a message per
error case and a link back to booking
- new Service_model::getBookingBySlotAndGuest(); if the guest's own booking for
that exact slot already exists the submit is a duplicate rather than a real
conflict, so finish normally instead of erroring. Guarded on a non-empty
e-mail, as admin block bookings are stored with an empty guest_email.
No schema change. Verified on test, dev and prod: friendly page in all three
languages and both skins, double submit redirects to booking-finished without
creating a duplicate row, and no raw JSON in any response.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01TJso3iGT7TkW5tm4RSBohs
Hitting /booking-process via GET (or any POST without sendBooking) fell
through past the form-submit guard and tripped three undefined-variable
warnings on the final sendEmail() call. Bail out to the site root
early, matching the pattern in manage_booking_process.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
Guests modifying a booking saw every worker for the subpage, so an
eyelash booking exposed nail-only workers as switchable. Now the worker
list is scoped to the booking's service category, other-category
services are disabled in step 1, and the process handler rejects any
worker/service category mismatch to defend against crafted POSTs.
Co-Authored-By: Claude Opus 4.7 <noreply@anthropic.com>
- getAvailableTimes() takes optional exclude_booking_id so a guest's
own booking isn't counted as a conflict when editing — original time
now reappears when extending services
- Manage-booking AJAX passes manage_token; server resolves to booking_id
- manage_booking_process uses the new param instead of the date-swap
workaround (removes a small race-condition risk)
- Modify-booking emails (no/en/hu) now include Name/Email/Phone rows
and the 24h cancellation policy, matching the original booking email
- Lunch slot no longer pre-blocked; a slot is only unavailable if
booking it would eliminate the last possible 30-min break window
- Added preferred lunch time per worker (closest-to-preferred slot wins)
- Lunch break only applies for shifts >= 6 hours
- Google Calendar: lunch event created/updated/deleted on every
booking create, modify, or cancel via _syncLunchCalendarEvent()
- New table worker_lunch_gcal_events tracks lunch event IDs per worker/date
- New model methods: getBookingsForWorkerDay, getLunchGcalEventId,
upsertLunchGcalEventId, deleteLunchGcalEventRecord, getBookingsForWorkerMonth,
computeLunchBreak
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Evelin receives all booking notifications via the shared ntfy topic in config.
Each worker also gets notified on their own personal ntfy topic (set per-worker
in the admin panel) — so workers only see their own booking events.
- _ntfy() now accepts optional $workerTopic and sends to both topics if different
- All three call sites (new/modify/cancel) pass $worker->ntfy_topic
- Admin worker form + worker_process() wired for ntfy_topic field
- DB: ALTER TABLE workers ADD COLUMN ntfy_topic VARCHAR(100) NULL DEFAULT NULL
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Sends instant push notification on new booking, modification, and
cancellation. Set ntfy_topic in application/config/google_calendar.php
to activate. No-ops silently if topic is empty.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Service account can now impersonate a Workspace user (set gcal_impersonate_email
in config) to unlock attendee invitations with push notifications.
Falls back to silent event creation if impersonation is not configured.
Setup required in Google Admin Console:
Security → API Controls → Domain-wide delegation
→ Add service account client_id with scope:
https://www.googleapis.com/auth/calendar
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Google API forbids attendees on service account events without
Domain-Wide Delegation (requires Google Workspace). Reverts to
direct event creation which works with personal Gmail calendars.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Add attendees to calendar events with sendUpdates=all so workers and
Evelin receive an instant push notification + invitation email when a
booking is created or modified, instead of the event silently appearing.
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
- New GoogleCalendar library: createEvent/updateEvent/deleteEvent via service account, all wrapped in try/catch so failures never break booking flow
- booking_process: creates worker + owner calendar events on new booking
- manage_booking_process: deletes old events, creates new ones on modify
- manage_booking_cancel: deletes events before cancellation
- Service_model: updateBookingCalEvents() stores gcal event IDs
- Admin worker form: Google Calendar ID field added
- PHPMailer: enabled exceptions (was silently swallowing SMTP errors)
- Config: application/config/google_calendar.php for service account path + Evelin calendar ID
DB migration required:
ALTER TABLE workers ADD COLUMN google_calendar_id VARCHAR(255) NULL DEFAULT NULL;
ALTER TABLE bookings ADD COLUMN gcal_event_id_worker VARCHAR(255) NULL DEFAULT NULL;
ALTER TABLE bookings ADD COLUMN gcal_event_id_owner VARCHAR(255) NULL DEFAULT NULL;
Co-Authored-By: Claude Sonnet 4.6 <noreply@anthropic.com>
Astral04andClaude Sonnet 4.6