More filtering options for the overview

[raninehme]

Hi! Another small suggestion for the overview/dashboard.

It would be useful to have a bit more control over what appears there, especially for shared households.

For the calendar widget, I would like an option to show only events assigned to me instead of seeing everything from other members as well.

For the task section at the top, it would also be useful to choose which task categories are included.

For example:

• Calendar: All / Assigned to me
• Tasks: choose specific categories to show

Since the dashboard settings already apply per user, this would make the overview much easier to personalize without affecting the rest of the household.

Thanks for considering it!

[ulsklyc]

Agreed on both, and they are the same piece of work: the overview needs per-widget options rather than one more global switch.

Your framing is the useful part. The dashboard configuration is already per user - order, visibility and size of each widget are stored against your account - so the natural place for "calendar: all / assigned to me" and "tasks: these categories" is the same object, one level deeper. That keeps it personal by construction: you narrowing your own overview cannot change what anyone else sees.

Two things it has to get right, and neither is obvious from the outside.

The first is where the filtering happens. The overview does not simply render what a module returns; it runs its own queries, and the task list caps at five while the metric tiles count without a limit. If a filter ran in the browser, you would see two rows under a tile saying seven. So the options have to travel with the request and narrow the query itself, before the cap - not afterwards.

The second is that the same rules must not get written down twice. That was the reason the overview and the Tasks module had already drifted apart on which tasks they show at all (#825): two copies of one rule, and only one of them got updated. That shared selection has just been fixed, and it is the foundation this builds on - options are worth adding only once there is a single place that understands them. Which is why it went first.

What the widget options will deliberately not be is a list the server knows about. Widget identifiers are owned by the frontend today, on purpose: adding or removing a widget never requires a matching backend change. The options will follow that - the server validates that they are a safe shape and stores them, the browser translates them into the query it sends. A server-side registry of every widget and its settings would be the cheaper way to start and the one that makes every future widget more expensive.

No date to promise. Filed together with #825 and #827, which are the other two parts of "the overview is too rigid".

[ulsklyc]

Built - both halves, as described above.

In customize mode the calendar and tasks tiles now carry a settings button: the calendar can be limited to appointments assigned to you, the task tiles to categories you choose. Both are stored with the rest of your layout, so they are personal by construction.

The two things I said it had to get right, and how they turned out:

The filtering travels with the request and narrows the query, before the cap. It also applies to everything the page says about tasks and appointments, not only the tile you set the option on - tasks appear in four places on that page (list, metric tile, the per-member "due today" card, the header band) and appointments in three. A page that filters half of itself contradicts the other half, which is the same failure as two rows under a tile that says seven, one level up.

The options are not a list the server knows. It stores them and validates only their shape; which widget understands which option stays with the frontend, exactly like widget ids, so adding a widget still requires no backend change.

One thing I had not expected: making the overview's category filter share the Tasks module's fragment surfaced a real bug in the module itself. GET /api/v1/tasks?category=a&category=b bound the array into a single placeholder, so a second category did not just fail to filter, the request failed outright. Several categories now combine with OR there too, like status, priority and assignee already did.

"Assigned to me" means the same as in the calendar module: among the assignees, so an unassigned event is not "mine".

Released in v2.35.0.

[raninehme]

Thank you for implementing both parts so quickly! Having the filters applied at query level and consistently across every relevant part of the overview sounds like the right approach, especially with the different limits and counts. Nice catch on the multiple-category API bug as well.

I’m currently installing v2.36.0 and will test all three of my requests together.