fix(facilities): let a facility record which sport it hosts
facility_activities.academy_id is NOT NULL and the pivot has no model to stamp
it, so $facility->activities()->sync([...]) threw a not-null violation. Both
write paths use exactly that call — FacilityService::create() and
FacilityForm::save() — so ticking a sport on a facility has never once worked on
any tenant. It surfaces only on Postgres, and the default sqlite suite has no
such table, which is why nothing caught it.
The consequence was quiet rather than loud: 2026_08_30_000003 treats a facility
with no rows here as one that hosts anything, so instead of an error the
schedule builder just kept offering every group in the academy for every pitch —
the thing that migration was written to stop. A football pitch still lists
swimming groups.
Fixed on the relation with withPivotValue(), which both fills the column on
write and scopes it on read, so the edit path is covered too without either
caller having to remember.
Also null-coalesces the two optional keys in validateNoOverlap(). Neither is
passed by createDefaultLayout(), so every facility ever created raised
"Undefined array key" — a warning in the app, a hard error under PHPUnit. The
deeper issue is left alone on purpose and noted in place: a null day compiles to
`effective_day_of_week = NULL`, which SQL never satisfies, so an all-days layout
is currently exempt from overlap detection. Every tenant already has an
auto-created all-days default layout, so making it collide would start refusing
temporal layouts that can be added today — a behaviour change that wants its own
decision, not a drive-by.
Co-Authored-By:
Claude Opus 5 (1M context) <noreply@anthropic.com>
Showing
Please register or sign in to comment