Community
Participate
Working Groups
New working set configuration ui don't allow to pick Archive category, hence don't allow to create working set that would show orphaned tasks. This is critical because tasks that not match query dropped out of the view. Using archive category in the working set is really ugly workaround to current "feature" that query node silently drop unmatching tasks. It is ugly because when you select Archive category for the working set, then all changed tasks from all repositories will appear in there. So, query should show unmatching changes as "unread" deletions and only drop them after user mark them as read or open them in the task editor. But even then it will be extremely useful to retain origin of those tasks, so they won't be dumped into Archive category, which really quick became messy.
I'm concerned that it is a bad idea to add this and that the better tradeoff is to only have things show in the working set that explicitly match it. Orphaned tasks can always be noticed by showing all working sets which is the only way to be sure that no incomings have been missed.
Showing all working sets will make working sets useless, because you don't know when to expect those orphaned tasks and have to flip working sets on and off. So, until query implementation would handle notification about dropped tasks I don't see other options.
The work-around for seeing tasks that don't match queries is simple: hit Show All. I do this once or twice a day and while it is not ideal, I see less more confusion come out of fixing this than leaving it. It is impossible for a user to know whether or not they should add the archive, so if anything it should be added automatically. But then we would lose the substantial benefit of not showing archive hits when Find is used and a working set is selected.
"once a day" don't really work if you are within some working sets. Especially when query is something like "my tasks" and tasks get reassigned, moved or closed back and forth. Loosing notification about that hurt quite bad.
I caught myself that I simply forgot to use "show all" that been suggested to be used as a workaround for this issue. In result I've missed few dozen issues that required my attention for several days. So, what is the current plan in regards to this issue?
What I think a reasonable compromise would be to have the content provider use something like the following rule when showing the archive while a working set is selected: If the task is not visible in one of the query containers and the repository for that task is one of the repositories of a query in the working set Then add the task to a repository container node and add that node to the Archive node Will consider for 2.1 or take a patch (as long as we agree on the design first). This might be too complicated for a patch though because we might need to wire up having tasks know the queries that contain them, which is a shortcoming that kept us from doing this and similar changes.
Need to postopone to 2.2, for which we should consider other archive category improvements.
Part of bug 181388.
Fixed is included with patch on bug#181388.
Fixed.
