Asked for directly: alongside "Lancer cette playlist" (always from the
first item), a way to start a playlist party from any chosen item.
views/playlist/Playlist.ts's own top comment used to rule this out,
written back when the page was deliberately read-only - the stated
reason was that a playlist item carries no back-reference to whichever
playlist it came from, unlike an Episode's own SeriesId, so "start from
item N, queue the rest" wasn't reconstructable the way views/series
does it for episodes.
That reasoning was correct for a bare item id on its own, but doesn't
actually block this exact page: renderPlaylist already fetches the
entire, ordered item list just to render it, so "item N of playlist P"
only ever needed playlist P's own already-in-hand list, never a
back-reference on the item itself. views/library's tiles and
views/album's per-track rows still can't do this - neither has that
ordered list around - which is why the feature lives only here.
createParty(itemId, startAtItemId?) gained the optional second
argument, threaded through POST /api/parties into
createPartyFromPlaylist (index.ts) - meaningless for every other item
type, so every other call site keeps working with just one argument.
createPartyFromPlaylist resolves it against the playlist's own
(post-splitPlaylistByMediaType) item list and slices from there, the
same "slice, don't wrap" shape the single-item path already uses for
SeriesId-based episode starts. Everything before the chosen item is
simply left out of the party, not queued for later - true for both
video and music.
Each row in the playlist page gets its own "Lire à partir d'ici"
button now, mirroring views/series' own per-episode button (reuses
.episodeRow's existing styling/responsive wrap, no new CSS). Both it
and the existing "Lancer cette playlist" button funnel through one
shared launch() helper.
Verified: full typecheck/test/build on both projects (118/118 server
tests - no dedicated test added for createPartyFromPlaylist itself,
consistent with this project's existing boundary that index.ts's route
glue isn't unit-tested, only the services it calls into are). Confirmed
in a real browser against the compiled bundle that the new per-row
button renders correctly at both desktop and phone width.
Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
Nicolas
cf82ea5c2d