Workouts were private to their owner with no way to browse or copy
another user's - FavoriteController::toggleWorkout even had a comment
anticipating sharing ("users can still favorite others' workouts if
shared later") that was never followed up on.
Adds an is_public flag workouts can be toggled to from their own page,
a /workouts/community browse+search page, and a copy action that
duplicates a public workout (including all its exercises/sets/reps)
into the copier's own library.
Making this work required splitting workout authorization into two
tiers: authorizeView() (owner, the assigning trainer, or anyone if the
workout is public - read-only) and the existing authorizeWorkout()
(owner or assigning trainer - can add/edit/remove exercises). Deletion
stays strictly owner-only as before. The show page now hides the
"Add Exercise" panel and per-exercise edit/remove controls for viewers
who can see but not manage a workout.
Found and fixed a real Blade compiler quirk via live testing: `@if`
directly after a word character with no space (`exercises@if(...)`)
doesn't compile - Blade's directive regex treats it as email-like text
and leaves it literal - while the matching `@endif` still compiles,
producing invalid mismatched PHP. Fixed by adding a space.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
is_trainer was captured at signup and stored, but nothing in the app
used it - no client roster, no way to assign anything, a dead flag that
misled users who checked it during registration.
Adds a trainer/client link (a trainer adds a client by the email they
registered with) and lets a trainer create workouts directly on a
client's account (assigned_by_trainer_id on workouts). Deliberately
scoped for privacy: a trainer only ever sees/manages the workouts they
authored and assigned - not a client's other private data (their own
workouts, weight log, health notes, session/completion history). That
boundary needs a consent or notification system to relax safely, which
doesn't exist yet, so it's left for a follow-up rather than building it
half-safe.
WorkoutController's authorization now distinguishes "manage" (owner or
assigning trainer - view, add/edit exercises) from "own" (owner only -
delete), so a trainer can build out an assigned workout's exercises
after creating it, but can't delete a client's workout out from under
them.
Found a real bug via live testing before committing: the client roster
page eager-loaded `assignedWorkouts` (keyed by assigned_by_trainer_id)
on each client record, which is the trainer's own perspective, not the
client's - so it silently showed "no workouts assigned" even after
assigning one. Fixed to eager-load `workouts` filtered by
assigned_by_trainer_id instead, with a regression test.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
The workout builder's "add exercise" dropdown was Exercise::orderBy
('name')->limit(50) with no search. Harmless with a handful of seeded
exercises, but once the library is populated with real data (1000+),
users could only ever add exercises starting around A-D - the core
"build a workout" flow would be effectively broken.
Replaces it with a debounced Alpine.js combobox backed by a new
GET /workouts/{workout}/exercises/search endpoint (owner-only, JSON,
capped at 20 results, respects each user's custom exercise aliases).
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
rootandClaude Sonnet 5