fix(study): scope the tag filter to the tags the studied tree owns #822

Merged

raisondetredev merged 1 commit from refs/pull/822/head into main

2026-08-05 12:47:36 +02:00

raisondetredev commented

2026-08-05 12:47:16 +02:00

(Migrated from codeberg.org)

selectedTagIds is one global preference, but a tag row belongs to a
single studyset tree. Tags picked while studying one deck stay selected
when the next session starts somewhere else, where they can match no
card at all, and _applyTagFilter then drops the entire pool. The
sheet cannot show the selection either: its picker lists this tree's
content tags, and ids from another tree simply aren't among them. So the
filter reads as off while silently emptying the queue, and the only
visible difference between "you're up to date" and "your filter matched
nothing" is that Reset happens to be enabled.

The session now resolves the selection against the same source the
picker uses — listForTree under the tree root — before deciding
whether a filter applies. A filter you cannot see is a filter that does
not apply.

A selection this tree DOES own is left alone even when it matches
nothing: that one is visible and clearable, and quietly widening it
would be its own surprise. A failed lookup keeps the raw selection
rather than silently studying unfiltered.

The repository is injected nullable, so the tests that don't wire it
build the same queue they always did.

Signed-off-by: Tizian 「ティツィアーン」 raisondetredev@pm.me

Opening a studyset with hundreds of cards due could land straight on "Nothing to study right now", with the study settings sheet showing no tag selected. Pressing Reset — the button that clears the tag filter — fixed it, which is the tell: the filter was set, and nothing on screen said so. `selectedTagIds` is one global preference, but a tag row belongs to a single studyset tree. Tags picked while studying one deck stay selected when the next session starts somewhere else, where they can match no card at all, and `_applyTagFilter` then drops the entire pool. The sheet cannot show the selection either: its picker lists this tree's content tags, and ids from another tree simply aren't among them. So the filter reads as off while silently emptying the queue, and the only visible difference between "you're up to date" and "your filter matched nothing" is that Reset happens to be enabled. The session now resolves the selection against the same source the picker uses — `listForTree` under the tree root — before deciding whether a filter applies. A filter you cannot see is a filter that does not apply. A selection this tree DOES own is left alone even when it matches nothing: that one is visible and clearable, and quietly widening it would be its own surprise. A failed lookup keeps the raw selection rather than silently studying unfiltered. The repository is injected nullable, so the tests that don't wire it build the same queue they always did. Signed-off-by: Tizian 「ティツィアーン」 <raisondetredev@pm.me>