Do you have screenshots of a scenario? That would be much appreciated to illustrate the issue & solution. :)

Do you have screenshots of a scenario? That would be much appreciated to illustrate the issue & solution. :)

This is an example for the starred collection which shows important tasks, but it works for the other collections just the same way.

Before this PR the starred collection looks like this:

It shows two important tasks, which are shown because they are important and root tasks. What it does not show is that there are two more important tasks which are subtasks of an other task.

With this PR, also important subtasks show up in the starred collection:

Now the important subtasks lead to the task Test 5 being shown, also showing the important subtasks. I think, this is the better behaviour, since you now really see all important tasks (subtasks or not).

What I would propose to additionally add is a counter showing the number of sub(sub..)tasks matching this collection (e.g. in a colored circle). So the task Test 5 will have a counter 2 , the task Test 5 - Subtask 1 will show 2 as well and Test 5 - Subtask 1 - Subtask 2 will show 1.

One more question would be now, what the counter in the app-sidebar shows. It could show 3 as it does at the moment with this PR (second screenshot), countin all root tasks. Or it could show the actual number of important tasks, namely 4 in that case.

I would say (if I got this right), for the task 5, always show the full task tree if it leads to a starred task.
But don't show any sibling/children tasks that does not contain nor are favourited :)

I would say (if I got this right), for the task 5, always show the full task tree if it leads to a starred task.
But don't show any sibling/children tasks that does not contain nor are favourited :)

That would be an option as well.

Hmm, so when you favorited a child task at the 3rd level deep, why not just show only that? That would simplify the whole structure a lot and not make the tree structure necessary. Viewing favorites is about focusing, and the structure might detract.

Otherwise we can do it like you and @skjnldsv proposed – show the structure for reference, but leave out siblings which are not favorited.

I think not showing the full tree might be confusing. You expect a subtask to be shown as a subtask.

I will implement it as @skjnldsv proposed it. Show the tree if it leads to a starred subtask. I will then show the number of other (not shown) subtasks as a number with a tooltip. When you open the details of this task showing all subtasks then might be good as well.

Codecov Report

Merging #431 into master will increase coverage by 15.32%.
The diff coverage is 82.02%.

@@             Coverage Diff             @@
##           master     #431       +/-   ##
===========================================
+ Coverage   11.13%   26.46%   +15.32%     
===========================================
  Files          44       44               
  Lines        2047     2086       +39     
  Branches      367      386       +19     
===========================================
+ Hits          228      552      +324     
+ Misses       1685     1417      -268     
+ Partials      134      117       -17

Now that it can happen that a task is shown multiple times in the week view (e.g. a task a two subtasks due today and tomorrow) a task should only be shown as active if it is the very exact task.

• If a task is opened on day 1, don't also show it open on day 2.
• Only show not matching subtasks for active tasks
• Show parent tasks if a descendant is open

@skjnldsv @jancborchardt This was quite a bit of work, but I think it is finally done.

With this PR all tasks (including subtasks) are shown if they match a collection. We show the full tree for subtasks matching the collection, but don't show siblings which don't match. When a task is open in the details view, all its subtasks are shown.

For the starred view this looks like this.

No task open in details view:

Task which is not matching the collection is open (showing all its subtasks):

Subtask which doesn't match the collection is open (still showing full tree to this subtask):

I also added a lot of tests to check for the correct behaviour of the collections.

What is still left to be done is to indicate which task exactly matches a collection and which one is only shown because a subtask matches. I would like to do this in a follow up PR, because this one is already quite huge.

I'm using 0.11.3 on 17.0.1 and this is still an issue, so it doesn't seem like it fixed the problem. Creating a subtask with a due date when the parent does not have a due date does not show that task in Important, Today, or Week.

This fix is not included in 0.11.3. It will be released with 0.12.0.