Community
Participate
Working Groups
I have a subtask of a task that is matched by a query, but it's a subtask that doesn't concern me at all. I would like to be able say that I do not want to be notified of changes to this subtask.
Another use case is that I was getting an NPE due to a recent commit by someone else, found the relevant task and posted a message about the NPE, and now that it's been fixed, I don't care about that task. In this case I would almost like to actually be able to delete the task from my task list and have it not be added back by the query.
(In reply to comment #1) > Another use case is that I was getting an NPE due to a recent commit by someone > else, found the relevant task and posted a message about the NPE, and now that > it's been fixed, I don't care about that task. In this case I would almost like > to actually be able to delete the task from my task list and have it not be > added back by the query. With the fix for bug#283200 you can change the query be define an boolean chart that excludes the no longer needed task. The other case need some extra work. I hope that I can look into this in the next week.
I keep seeing this surface as a major cause of task lists getting overloaded with incomings. What if we create a dialog or even a simple preference page that allows the user to control over incoming notifications, and turn this one off by default? My only concern in this case is whether these should show at all. I find it very weird that I would have a query that explicitly says that I should be excluded from things I'm not CC'd on, yet see subtasks that I'm not CC'd on.
I think you would still want to be notified when someone creates a subtask of a task in your task list, and it could be annoying to have to manually add subtasks to your task list. I'm thinking it might be good to have a per-task setting that controls how subtasks of that task are handled.
My assumption is that if you are explicitly excluding everything that you are not CC'd on, to have a subtask show in your Task List someone should CC you on it. Otherwise we get into the scenario where being CC'd on one higher-level task will mean that you can easily bring in 50 tasks that you don't care about. Then you end up ignoring those incomings or marking them as read, and might miss one where you got CC'd.
That makes sense. But I think I would still want to be notified about the creation of a direct subtask of a task in my list, even if I am not CC'd on the subtask, i.e. there should still be a notification on the parent task, without bringing the subtask into the task list.
My sense is that the task list is the personal view on the repository and should only show and notify on items explicitly subscribed to through a query or by adding individual tasks. Nevertheless it's often desirable to have fast offline access to subtasks and there are some limitations in the task list presentation that make it difficult to limit the structural view to items that actually match a query. I would propose that we separate what's being cached and what's being displayed in the task list and generally limit what's being shown under a query to exactly the items matched by the query. If needed we can always make that configurable on a per query basis to provide a "backwards" compatible mode that brings in subtasks as well.
(In reply to comment #6) > That makes sense. But I think I would still want to be notified about the > creation of a direct subtask of a task in my list, even if I am not CC'd on the > subtask, i.e. there should still be a notification on the parent task, without > bringing the subtask into the task list. Yes, that would always show as a change in the Depends On / Blocks fields.
Can we get this on for 3.5?
I'll work on a solution but I can't promise that it will be ready for 3.5.
Sounds reasonable.
Created attachment 190230 [details] wip v1
Created attachment 190231 [details] mylyn/context/zip
Created attachment 190343 [details] fix two
(In reply to comment #0) > I have a subtask of a task that is matched by a query, but it's a subtask that > doesn't concern me at all. I would like to be able say that I do not want to be > notified of changes to this subtask. The changes for bug 338499 add the ability to filter non matching subtasks from the task list. Note that this does not address the problem that a non-matching subtask may show under a query if another query brought it in. I am still working on that and will try to address it by using a path aware content provider.
Created attachment 190351 [details] first patch
I have committed the patch which ensures that only tasks that match a query are shown under it if "Show Non Matching Subtasks" is unchecked. Some inconsistencies remain: * If a repository task that matches a query drops from the query its subtasks do not end up in Umatched even if they were part of the query before. I believe this has always been broken and is unexpected and should be fixed in TaskList. * Repository tasks in categories only show the subtasks that are otherwise visible in the task list. This may be surprising and subtasks have to added to a task list category explicitly now to make them show if "Show Non Matching Subtasks" is unchecked. We could consider fixing this in the drop adapter by add the entire task hierarchy to a query and not only the top-level task but it makes removing tasks from queries more difficult as related tasks would remain in the category even if the parent is removed.
Created attachment 190359 [details] do not show notifications
I have committed the patch to also filter notification popups based on the task list filter settings. I think we are done here.
Now that filtering is working, would it make sense for the query to also bring parent tasks into the task list, but filter them when they do not match? That way they would be available offline.
(In reply to comment #19) > I have committed the patch to also filter notification popups based on the task > list filter settings. I think we are done here. When I had incomings on both visible and hidden tasks, I think there was a popup that showed both.
(In reply to comment #20) > Now that filtering is working, would it make sense for the query to also bring > parent tasks into the task list, but filter them when they do not match? That > way they would be available offline. I guess that would then bring in all the subtasks of all the parents, which would be way too much.
(In reply to comment #21) > (In reply to comment #19) > > I have committed the patch to also filter notification popups based on the > task > > list filter settings. I think we are done here. > > When I had incomings on both visible and hidden tasks, I think there was a popup > that showed both. Turns out I'm not quite as up to date as I thought I was, so that probably explains that.
(In reply to comment #23) > > When I had incomings on both visible and hidden tasks, I think there was a > popup > > that showed both. > > Turns out I'm not quite as up to date as I thought I was, so that probably > explains that. I missed that in the first round of changes but fixed it later on. Let me know if you are still seeing incomings for tasks not showing in the Task List with the latest.
May I say: thanks for bringing this up Sam, and thanks for implementing it Steffen. I never like pulling in subtasks, finally my queries can show what I want them to :)
(In reply to comment #17) > I have committed the patch which ensures that only tasks that match a query are > shown under it if "Show Non Matching Subtasks" is unchecked. > > Some inconsistencies remain: > * If a repository task that matches a query drops from the query its subtasks do > not end up in Umatched even if they were part of the query before. I believe > this has always been broken and is unexpected and should be fixed in TaskList. > > * Repository tasks in categories only show the subtasks that are otherwise > visible in the task list. This may be surprising and subtasks have to added to a > task list category explicitly now to make them show if "Show Non Matching > Subtasks" is unchecked. We could consider fixing this in the drop adapter by add > the entire task hierarchy to a query and not only the top-level task but it > makes removing tasks from queries more difficult as related tasks would remain > in the category even if the parent is removed. Steffen, are there tasks to address these issues? Is there any plan to hide non-matching subtasks by default?
