Community
Participate
Working Groups
Result of the Bugzilla query could be very big (e.g. choose all bugs in all statuses on JDT for last 30 days) and it probably would make sence to not download the entire resultset or somehow implement pagination for such large resultsets. Also, when task filter is applied on query results Mylar can probably requery server (if supported) using entered filter text. That would help to monitor CVS activities when commit comment does not have bug description.
Shawn: let's try to put this limit on this week. When the limit is hit, we can add this info to the category label, e.g. something like: My open bugs <first 50 hits> Eugene: I understand your point about making the queries smarter using filtered text. But this probably means that our filtered text becomes an actual search, and not just a filter of the tree (something we have considered, but involves a lot more work and performance would be an issue). But could you clarify what you mean about monitoring CVS activities?
(In reply to comment #1) > Eugene: I understand your point about making the queries smarter using filtered > text. But this probably means that our filtered text becomes an actual search, > and not just a filter of the tree (something we have considered, but involves a > lot more work and performance would be an issue). I believe limit as you've suggested makes sence for a large query results. In regards to using filter as an actual search criteria on description/id - I think that it would be the most appropriate way of doing this. If implemented in a right way, it shouldn't have performance issues. So, here is how I think it should be done: -- No filter. Query repository and show results (up to configured limit). Memorize if query had been shown entirely (so, won't need to requery server) -- User typed something in a filter. Immediately filter-out in memory representation and mark all partial queries italic. -- In 1..2 seconds after user typed last char in a filter (probably should be also configurable) or when previous job is finished, query server using a background job without blocking UI, -- Upon query completion add new entries into the previously filtered list and remove italic decoration. > But could you clarify what you mean about monitoring CVS activities? Well, when you run syncronize and see bunch of incoming changes with comment like "107085, 107086" you sort of curious what the hack these bugs was about. Now I have to manually add them into the mylar task list in order to see description. It would be faster to be able to just type issue id. Another "fancy" way of doing this could be to drag resource (or folder/commit set on "commit sets" mode) from Synchronize view into the Mylar task list view and Mylar would try to find matching issues and add them as tasks. But I believe it would require too much heuristic.
for now, if you just want to type the issue id, open the eclipse search dialog and the bugzilla search page allows you to enter the issue id in the summary field to open that specific bug
should there then be a way to get all of the bugs since the list doesn't have everything that u might want to see? and do we want to get the highest pri, sorted by bug id, assignee, etc
How about a preference that says Limit query hits to [ ] And is set to 100 by default? If it is easy to get only trim the lower-priority resutls then that's good. I think that with a sufficiently high default limit (like 100), we don't need to worry about adding a new action like "Download all reports". But we could add it later if users complain. Eugene: note that I copied some of your comment #2 suggestions to bug 106862, which I'd like to make some progress on for next week's release.
support for this has now been added. The default is 100 and can be configured through the preferences.
(In reply to comment #6) > support for this has now been added. The default is 100 and can be configured > through the preferences. Per-query I presume?
Eugene, on comment #2 you made some interesting points about a slightly different search/filter interaction. If you still want something like after trying 0.3.5 next week could you please raise a new enhancement request?
Actually, this was added as a global option. I can look into making it per query though.
(In reply to comment #9) > Actually, this was added as a global option. I can look into making it per > query though. Thanks. I should of make it more clear earlier. Sorry about this.
The global option is important because it will prevent people from accidentally getting hundreds of matches. Bug on the query page you can add a "Limit to", and have the default there be the global option number.
Eugnee, regarding the last paragraph of comment #2, do you want to make a new enhancement request for drag-and-dropping task bug contexts or something along those lines? Can't promise that we'll get to this soon but I like the idea too, and we have a few other cases for similar functionality. E.g. you could drag a stack trace, unit test, and such things in order to automatically populate context.
(In reply to comment #12) > Eugnee, regarding the last paragraph of comment #2, do you want to make a new > enhancement request for drag-and-dropping task bug contexts or something along > those lines? Can't promise that we'll get to this soon but I like the idea too, > and we have a few other cases for similar functionality. E.g. you could drag a > stack trace, unit test, and such things in order to automatically populate context. Mik, I'd rather hold it until Mylar will have support for multiple issue repositories and issue with linking version control systems with issue repositories will be resolved.
Support has now been added so that the number of hits returned can be specified per query. If no number is specified, all of the hits will be returned. The global number is used for the default value that is in that box
