Community
Participate
Working Groups
currently, when tasks became not matching to the given query criteria, query synchronization is silently removes them from query and drop into the archive. there are at least two issues with this approach: -- user don't see this transition and can miss some important information because of that -- archive is not being shown when task working set is active which makes above issue even worse so, I believe task synchronization should keep non-matching tasks under query until user will mark them as read either explicitly, or implicitly by opening the task editor.
Related to archive category organization (bug 15270).
Also related to bug 201157
One more use case: in some JIRA configurations people implement a custom workflow, so, after developer resolve, issue it is reassigned to QA person, and after verifying it, it is reassigned to a dummy assignee, to indicate that no one is working on it anymore. Sometimes, after issue is assigned to developer, QA folks can close it (for example if it been fixed elsewhere or can't be reproduced anymore) and in result developer won't see this change because issue will suddenly disappear from the task list. The only workaround is to use query that will bring all repository tasks locally, but that does not work very well with JIRA on large task repositories.
As per the UI design discussions on our calls, I think that it is important for us to preserve the invariant that only elements matching a container (e.g. query) appear under that container. Changing this will make the Task List interaction considerably more complex and more similar to that of the Synchronize view, which is an incoming/outgoing layer over top of a canonical resource view (e.g. Package Explorer). I think it is important for the Task List to avoid showing transitional states, and always show the canonical state. Marking as WONTFIX, but if the changes on bug 181388 don't address some of the most problematic use cases we can reconsider. Added some notes to: http://wiki.eclipse.org/Mylyn_Focused_UI_Design#Information_Design
(In reply to comment #4) > ...preserve the invariant that only elements matching a container (e.g. > query) appear under that container... Please note that such invariant is temporal and in fact task may not match query anymore. You can pretty much get into the same situation by synchronizing single task under query, so you'll see updated task under query while task won't be in fact matching that query. > Changing this will make the Task List > interaction considerably more complex and more similar to that of the > Synchronize view, which is an incoming/outgoing layer over top of a canonical > resource view (e.g. Package Explorer). That is not what been suggested. There is already "read/unread" state for each task, so the proposal was to stick "unread" tasks on their old slots until they are "read". Basically give user chance to review the changes, i.e. to see where bug been moved to or whom it been reassigned. This kind of information is not addressed by planned changes for archive category and all in all the wontfix resolution for this issue is very disappointing.
(In reply to comment #5) > That is not what been suggested. There is already "read/unread" state for each > task, so the proposal was to stick "unread" tasks on their old slots until they > are "read". Basically give user chance to review the changes, i.e. to see where > bug been moved to or whom it been reassigned. We have a very different point of view on this, and I don't agree with your assessment. Sorry that you are disappointed, but until we have concrete examples of UIs that do what you propose in a simple way we will retain the existing approach.
(In reply to comment #6) > ...until we have concrete examples of UIs that do what you propose in a > simple way we will retain the existing approach. In my recollection, concrete examples been discussed on calls in much more details then usability problems you've mentioned on bug 181388 comment 14. It will be useful to hear about these usability problems in more details. Here is suggested interaction: -- after synchronization keep removed task under original query and use "-" marker (or variant) to indicate removal. Then, then task is marked read, either using "mark read action", or on editor opening, it is cleaned up from the originating query. -- if after synchronization above task is matching some other query, it will appear in both queries (one where it been removed from will show "-" marker and new one will show regular "changed" marker) and when task is marked as "read" both places will be cleaned up. This way user interaction in regards to read tasks won't change, except that moved or removed tasks will be visible.
