Add filter to Tasks in Overview

[Interfectoro]

Currently all recurring tasks and subtasks are displayed on the overview regardless of the filter applied on the tasks module.

This causes the tasks overview to be cluttered and hard to distinguish important tasks from recurring ones that will happen later.

Ideally, there would be an option to apply the same filtering of the tasks module to the overview. Or some other option to filter out subtasks and later tasks.

Thank you!

[ulsklyc]

Two of the three things you describe were a bug, and they are fixed - the change is on its way into the next release.

Subtasks and later tasks. The overview and the Tasks module answer the same question, and each had its own copy of the rules. The module leaves out subtasks and anything with a start date in the future; the overview knew neither rule, so a subtask stood there as a line of its own without the task it belongs to, and something starting next week was already sitting in your list today. That was not a missing setting - it was a rule one side never got. Both now share the same selection, and so do the metric tiles above the list: those count without a limit while the list caps at five, so filtering only the list would have put two rows under a tile claiming four.

While moving it, a third copy turned up: the MCP tool list_tasks had one of the two rules and not the other, so an automation was being told about tasks that will not start for another week. Same fix.

The recurring part I want to check with you before I touch anything. Recurring tasks in Yuvomi are not materialised into future instances - a recurring task is one row whose due date moves forward when you tick it off. So there is nothing to filter out in the sense the other two had. What I suspect you are seeing is this: a task that repeats daily or weekly is due again almost immediately, so it is permanently near the top, and the five slots the overview has get taken by the same chores every day while a one-off task that actually matters gets pushed out.

If that is it, then the honest fix is not a filter but the ordering - the overview sorts by overdue, then due date, then priority, and a daily chore wins that comparison every single day. Does that match what you see? And if it does: would you rather have recurring tasks off the overview entirely, or ranked lower so they only appear once the important things are done?

On applying the module's filters to the overview, which is what you asked for literally: that is a separate piece of work, and it is planned - the overview would get per-widget options, so you could pick which categories the task widget shows. It needs the shared selection above as a foundation, which is why that came first. It is tracked alongside #814, which asks for the same thing from the calendar side.

[ulsklyc]

All three parts of this have shipped.

The two that were bugs are in v2.32.0. The overview and the Tasks module now share one selection instead of each keeping its own copy of the rules: subtasks stay with the task they belong to instead of standing as context-free lines, and something that only starts next week is no longer sitting in today's list. The metric tiles above the list count on the same basis, so the number over a tile and the rows under it can no longer disagree. The same axis reached the MCP tool list_tasks as an include_future flag, off by default - an automation should be told what the app shows, not more.

The filter you actually asked for is in v2.35.0. Customize mode now carries a settings button on the calendar and task tiles: the task tiles can be limited to categories you choose, the calendar to appointments assigned to you. It is stored with the rest of your layout, so it is yours alone - narrowing your overview changes nothing for anyone else in the household.

The filtering happens in the query rather than in the browser, and it applies to every part of the page that talks about tasks, not just one tile. A page that filters half of itself would contradict the other half.

Thank you for the report - the first half turned out to be a rule that one side had never received, which is the kind of thing that stays invisible until someone describes what they see.