Category: enhancement
Summary: Add a Playlist lens (sort + free-text filter) to the Playlist page, including an "Added on" sort backed by a new optional entry-level added_at from Sources.

Current behavior:
A Playlist page shows entries in stored (manual, drag-reorderable) order only. There is no sort or filter. Entries carry no timestamp, and the plugin-api has no added-at on Source playlist tracks. Play, play-from-row and Add to queue operate on the stored order.

Desired behavior:
The Playlist page gains a Playlist lens (see GLOSSARY.md): a sort key + direction and a filter text. It is a view over the stored order and never changes it, including on Linked Playlists (nothing is mirrored to the Source).

Sort keys: manual order (default), title, artist, album, duration, added on. Picking a key sorts ascending; picking the active key again flips direction. Ties fall back to stored order. Entries with no album sort last for album.
Added on: dated entries sort by date; undated entries (app-only entries predating this change, Sources that report none) always come after dated ones, in stored order, in both directions.
Filter: one free-text box, case-insensitive substring over title, artist and album. Empty text means no filter.
While any sort other than manual or any filter is active, drag-to-reorder is disabled.
Play, Add to queue, and play-from-row use what is shown: the visible entries in visible order. A play started from a lens still records the Playlist as the Queue's context.
The lens is remembered per Playlist, per Device, in UI local storage (storage failures must degrade to "no remembered lens"). Provide a way to see that a lens is active and to reset it.
"Added on" data: the plugin contract's playlist-entry result gains an optional added-at; the Deezer plugin fills it from the Source's per-track playlist add time. Core stores it per Playlist entry. Entries added in Medley are stamped by the app at add time; linked entries take the Source's value when provided.

Key interfaces:

PlaylistEntry (core and its UI core.ts mirror): optional added_at (timestamp).
The plugin-api type returned for a Source playlist's tracks: optional added-at on the entry (not on Track, since it describes Playlist membership). Additive and optional so existing plugins keep working.
Core::play_playlist / play_playlist command and add_playlist_to_queue: must accept an ordered subset of entry ids (or equivalent) so the shown order and filter drive playback while the Queue context stays the Playlist.
A pure UI function mapping (entries, lens) → visible entries, unit-testable with vitest.

Acceptance criteria:

Sorting by each of title, artist, album, duration, added on works in both directions; manual order restores stored order.
Undated entries come after dated ones under Added on, in stored order, in both directions.
Filter matches title, artist and album case-insensitively; non-matching entries are hidden.
Drag-reorder is disabled while sort ≠ manual or filter is non-empty, and works as before otherwise.
Play, play-from-row and Add to queue under a lens queue exactly the visible entries in visible order; Queue context is still the Playlist.
The lens never alters stored order or issues a Source mutation (verified on a Linked Playlist).
The lens persists per Playlist across navigation and restart; a missing or broken storage renders the Playlist unsorted and unfiltered.
A Deezer-linked Playlist's entries show Added on dates from the Source; Medley-added entries get an app stamp; old entries are undated.
Core tests (single test file, not the whole suite) cover storing added_at and playing an ordered subset; vitest covers the lens function.

Out of scope:

Reordering the stored Playlist from a sort ("apply sort as order").
Structured filters (Source, Offline, unavailable) and any filter beyond title/artist/album text.
Lens on Library views, albums, Queue, or plugin views.
Persisting the lens in core or syncing it between Devices.
Backfilling dates for existing app-only entries.

> *This was generated by AI during triage.* ## Agent Brief **Category:** enhancement **Summary:** Add a Playlist lens (sort + free-text filter) to the Playlist page, including an "Added on" sort backed by a new optional entry-level `added_at` from Sources. **Current behavior:** A Playlist page shows entries in stored (manual, drag-reorderable) order only. There is no sort or filter. Entries carry no timestamp, and the plugin-api has no added-at on Source playlist tracks. Play, play-from-row and Add to queue operate on the stored order. **Desired behavior:** The Playlist page gains a **Playlist lens** (see `GLOSSARY.md`): a sort key + direction and a filter text. It is a view over the stored order and never changes it, including on Linked Playlists (nothing is mirrored to the Source). - Sort keys: manual order (default), title, artist, album, duration, added on. Picking a key sorts ascending; picking the active key again flips direction. Ties fall back to stored order. Entries with no album sort last for album. - Added on: dated entries sort by date; undated entries (app-only entries predating this change, Sources that report none) always come after dated ones, in stored order, in both directions. - Filter: one free-text box, case-insensitive substring over title, artist and album. Empty text means no filter. - While any sort other than manual or any filter is active, drag-to-reorder is disabled. - Play, Add to queue, and play-from-row use what is shown: the visible entries in visible order. A play started from a lens still records the Playlist as the Queue's context. - The lens is remembered per Playlist, per Device, in UI local storage (storage failures must degrade to "no remembered lens"). Provide a way to see that a lens is active and to reset it. - "Added on" data: the plugin contract's playlist-entry result gains an optional added-at; the Deezer plugin fills it from the Source's per-track playlist add time. Core stores it per Playlist entry. Entries added in Medley are stamped by the app at add time; linked entries take the Source's value when provided. **Key interfaces:** - `PlaylistEntry` (core and its UI `core.ts` mirror): optional `added_at` (timestamp). - The plugin-api type returned for a Source playlist's tracks: optional added-at on the entry (not on `Track`, since it describes Playlist membership). Additive and optional so existing plugins keep working. - `Core::play_playlist` / `play_playlist` command and `add_playlist_to_queue`: must accept an ordered subset of entry ids (or equivalent) so the shown order and filter drive playback while the Queue context stays the Playlist. - A pure UI function mapping (entries, lens) → visible entries, unit-testable with vitest. **Acceptance criteria:** - [ ] Sorting by each of title, artist, album, duration, added on works in both directions; manual order restores stored order. - [ ] Undated entries come after dated ones under Added on, in stored order, in both directions. - [ ] Filter matches title, artist and album case-insensitively; non-matching entries are hidden. - [ ] Drag-reorder is disabled while sort ≠ manual or filter is non-empty, and works as before otherwise. - [ ] Play, play-from-row and Add to queue under a lens queue exactly the visible entries in visible order; Queue context is still the Playlist. - [ ] The lens never alters stored order or issues a Source mutation (verified on a Linked Playlist). - [ ] The lens persists per Playlist across navigation and restart; a missing or broken storage renders the Playlist unsorted and unfiltered. - [ ] A Deezer-linked Playlist's entries show Added on dates from the Source; Medley-added entries get an app stamp; old entries are undated. - [ ] Core tests (single test file, not the whole suite) cover storing `added_at` and playing an ordered subset; vitest covers the lens function. **Out of scope:** - Reordering the stored Playlist from a sort ("apply sort as order"). - Structured filters (Source, Offline, unavailable) and any filter beyond title/artist/album text. - Lens on Library views, albums, Queue, or plugin views. - Persisting the lens in core or syncing it between Devices. - Backfilling dates for existing app-only entries.

SBDeveloper added

ready-for-agent

and removed

needs-triage

labels

2026-10-13 21:47:16 +02:00