Community
Participate
Working Groups
It would be nice if i could combine multiple queries into one. Two examples: I have a SF project with 4 trackers. Right now I therefore have 4 queries. Instead, I would like to have just one Folder on the task list. Example 2: I am tracking multiple bugs from several projects i am not actively working on (such as this bug from eclipse, other bugs from codehaus, apache, etc.). I would like to have just one folder "My reported bugs" which I would use to combine the queries from all other bug trackers.
Max, you can still create multiple queries assigned to you, group them into some working set, then schedule each bug you are working on. Once it is done you can switch task list into "Scheduled" presentation mode, so you'll see all the bugs divided by scheduled dates.
The scheduling would work for those bugs on my own projects (1st example) However, for bugs that I am "just interested in" (like this one :) ), I do not want to schedule them for me at all... I would just like to look into it (and track it) from time to time, to see its progress. I have multiple issues like this outstanding on several bug tracking systems, and I would love to have them together in one category. (I hope this makes sense)
I can see how that could be convenient. However I am not sure if aggregating issues into same bucket/query would work well, because it will be hard to see where issue came from. For example, current tooltips in the Task List view show repository, but not the project or component issue belong to, perhaps because those attributes are specific for particular repository type and not standardized across connectors. Anyways, I see two options how this cane be implemented: -- add another presentation mode that would do some grouping, though it seems like UI and configuration for such presentation will be quite complicated. -- a simpler one is to add query support for the "Local Tasks" repository. The query configuration will be simply selector for other queries/categories from the task list
Created attachment 72846 [details] prototype of the aggregating local query Here is the working prototype for aggregating local query (no tests). This patch enables creating queries for the "Local Tasks" repository and provides UI for selecting queries/categories that need to be aggregated. Because connector's performQuery() method don't have access to the task list instance, I had to use special listener in tasks.ui in order to update content of the aggregating query when other queries/categories changed or removed. It seem working quite well in the result.
Created attachment 72847 [details] mylyn/context/zip
Mik, Rob, can you please look at this patch and tell me if it is worth to add this functionality (and keep the patch). Thanks.
Wow! That was not only a super-fast reply, but also a super-fast implementation! Now all I need is a binary version of the plugin to try this out! I just thought of another possibility: Maybe it would make sense to be able to put queries into categories? This way I can group multiple queries into one subset.
He he. Don't get too excited, because it may not go into the code, but you can setup dev workspace and apply this patch yourself. See http://wiki.eclipse.org/Mylyn_Contributor_Reference#Setup
Eugene: interesting, could you attach a screenshot? Max: The use case in your comment#2 is one of the reasons we allow the complexity of adding repository tasks from any query to a category (e.g. via drag-and-drop). Could you describe the scenarios in which adding the repository task to a category does not meet your needs?
Sure. First of all, let me start saying that I tried to drag'n'drop tasks from the queries, and it did absolutely nothing (Mac OS X). Is this known or should I open up a new bug report on that one? Then, moving single tasks into categories is only half the battle - new tasks will still show up in the other folders. So instead, maybe moving a whole query into a category would work. As I said, here is my scenario: - I have a project on SF with 4 trackers. Instead of having 4 folders for 4 queries, I would like to have them in one folder, or one folder with 4 subfolders, so that I can easily click it away. - I am committing bugs to several other trackers (such as this one, apache, etc.). However, these are not my main concern. So it would be nice If I could just create a category / folder "external bugs", where I could have all those (again, in subfolders if necessary, but rather as one list). Hope this makes sense.
Created attachment 73115 [details] screenshot (In reply to comment #9) > Eugene: interesting, I haven't heard this for quite some time... > could you attach a screenshot? Nothing terribly interesting, but here you are. It will require an additional query node, though agregated nodes can be filtered out with the working sets. To make things even easier, drag and drop could be used, i.e. dropping query to this node would add it ti the set (but this is not in the attached patch).
Do you want to make this a patch to the Sandbox? There have been several occasions where Rob and I discussed the potential that "local queries" like this could have, but we haven't collected enough use cases. Still, this seems worth experimenting with in the Sandbox where the usability and utility of this could get more feedback (e.g. Max could try it out). To do it in the Sandbox you might need to create a custom connector just for this, something along the lines of "CustomLocalQueryConnector", so before going down that road I suggest that you put a UI discussion regarding this on the next conference call agenda so that we can talk about whether prototyping this is best as a special kind of container or as a connector-based mechanism.
Mik, do you insist on this extra work?
(In reply to comment #13) > Mik, do you insist on this extra work? Yes, my point of view is that this would add significant UI complexity which will generate considerably more extra work for the project via bug reports or confusion of how queries should be used. This is a perfect candidate for the Sandbox, and if we need to do any extra work to make it easier to add this kind of thing to the Sandbox let me know what that is.
I think that creating whole new connector only to handle this special query type seem too heavy weight and will be even more obscured to the end users. I am not sure if you looked at the actual implementation, but it also don't really rely on query synchronization life cycle, and heavily using the listeners instead. So, I thought it was fairly simple UI that work on top of the existing connector added by default. Perhaps you could extract connector's query wizard into the extension point and provide default implementation for reading it in the AbstractRepositoryConnectorUi class, so it could be contributed by sandbox plugins (maybe they could even contribute more then one query wizard for given connector type). But then it will probably need another extension point for externalizing queries as opposed to coarse grained connector's externalizer.
What is our next action on this? Eugene, did you want to submit a patch for making your previous work contributable via sanbox?
Rob, you are asking the wrong guy. My last comment #15 haven't been answered.
Unfortunately we have way too many P1s and P2s for 2.2 to iterate on this enhancement right now. While this is a neat idea I think that it adds significant UI complexity and as such we should not consider it for 2.2 beyond a straightforward Sandbox patch. Leaving for 3.0 since I think it is worth exploring further.
FYI. I am dropping this patch from my workspace.
*** Bug 330617 has been marked as a duplicate of this bug. ***
Mylyn has been restructured, and our issue tracking has moved to GitHub [1]. We are closing ~14K Bugzilla issues to give the new team a fresh start. If you feel that this issue is still relevant, please create a new one on GitHub. [1] https://github.com/orgs/eclipse-mylyn
