I just had the problem where I had a bunch of bug lists up, and it's hard keeping track of them and what's what (suggesting parsing the URL is considered a capital offence). I suggest we put a summary after the quip on bug lists. I'm not sure if we should include any fields in this summary. It should at the very least include the stored query name, if applicable. If that's the only thing we do, the summary of course would only need appear if this is a stored query.

OK, stored query name seems to be over at bug #52228. I'd like to see the rest be discussed though before we mark the rest INVALID.

I think this would be useful. It could share code with one of the ideas on bug 15809, which is to provide a link from buglist.cgi to the same list but with unused query options stripped out.

I think the "Edit this query" link provides this functionality.

Stephen, I disagree. It would be good to see a short summary in the buglist by quick glance, without having to click on another link and waiting for the complex (and therefore slow) query page to show up.

What kind of summary would you like to see? If the query is a stored query then you could show the name but that's bug 52228. What would you display if it's not a stored query?

That's the question. Here's some random thoughts: To start with, I think the summary should depend on the query. We should try to show the most notable parts of the query. In other words, if a particular part of a query is the same as it usually is, there's no need to include it. We need to pass it through a filter of some sorts. For example, you wouldn't display that you're looking in 9 different products, but you might (and probably would) if it was just one. Then there's a need to rank the parts of the query and work out which are the most important to display. Maybe you might restrict the summary to three parts. Or we could just kill all this and let the user define a summary.

I think all parts of the query that restrict what bugs are shown should be listed. Maybe a <table> with... Status NEW/ASSIGNED/REOPENED [remove restriction] Reporter/CC (exact) davidr8@home.com [remove restriction] Summary (substring) modern [remove restriction] The order shown should probably be the same as the order on query.cgi, because bugzilla users are familiar with that order. For bonus points, don't include a field corresponding to a multi-select on query.cgi if all options are selected.

Well, we could do something like that. I was thinking about not polluting the bug list so much, but maybe it doesn't matter ...

It might be good to put that table at the bottom, since it would push the top of the bug list pretty far down on an 800x600 screen. I'd mostly use the table when - I forget what query is because I have too many windows open. In this case, I wouldn't mind scrolling down to the bottom to find out what the query is. - I make my query overly restrictive and got zarro boogs (in which case the bottom of the bug list would be on the screen). On the other hand, for some sort-by-id queries the bottom of the results page (most recent bugs) is more important than the top. Hmm, maybe the top is a better place for the table after all :P

If you decide to do this, could you make it optional? I don't want to clutter up the screen with a feature that I, personally, don't need.

See also bug 15809, which is about optimizing the query and buglist URLs. If this optimization would be implemented, I think it would be easy to generate some output like the mentioned table. Adding dependency.

The rfe in bug 96120 could help a little in managing bugzilla queries. But this is the best long-term solution.

Moving to new Bugzilla product ...

Whatever happens, bug#98123 will be needed to provide the user-prefs for a) whether to show this 'search criteria' info, b) how much to show, and c) where to put it (top/bottom/both)

I'll attach a patch in a bit which adds a small 'Search Criteria' table to the (2.14) buglist.cgi page. I'll also attach 2 examples of what the output looks like. There are hooks for the user prefs, when they are available. to enable people to turn the criteria on/off, and to specify where it goes, and how much it shows. It is not 100% complete, there are still some criteria to be processed, but it is a start, at least... This works by adding information to a list of search criteria as the SQL is generated, and does not do any sorting of the criteria - I haven't decided how best to do that yet.

We are currently trying to wrap up Bugzilla 2.16. We are now close enough to release time that anything that wasn't already ranked at P1 isn't going to make the cut. Thus this is being retargetted at 2.18. If you strongly disagree with this retargetting, please comment, however, be aware that we only have about 2 weeks left to review and test anything at this point, and we intend to devote this time to the remaining bugs that were designated as release blockers.

This is a simple solution, intended only to remind the user which buglist is in which window. The follow is what the output looks like. Bug List product=Product X AND bug_status=(NEW OR ASSIGNED OR REOPENED) AND attachments.ispatch equals 1

Comment on attachment 64496 [details] [diff] [review] less extensive/pretty impl. Needs-work because buglist.cgi has been rewritten after the patch was made. Also, the algorithm in this is too simple, as it removes (for example) a text query containing the word 'exact'. Maybe the query string should be split by & and analyzed thereafter, skipping unnecessary parameters?

nobody@bugzilla.org seems to care about these so they wont make 2.18. If someone adopts them, they can move them back. Retargetting to 2.20

Bugzilla 2.20 feature set is now frozen as of 15 Sept 2004. Anything flagged enhancement that hasn't already landed is being pushed out. If this bug is otherwise ready to land, we'll handle it on a case-by-case basis, please set the blocking2.20 flag to '?' if you think it qualifies.

*** Bug 282348 has been marked as a duplicate of this bug. ***

The trunk is now frozen to prepare Bugzilla 2.22. Only bug fixes are accepted, no enhancement bugs. As this bug has a pretty low activity (especially from the assignee), it's retargetted to ---. If you want to work on it and you think you can have it fixed for 2.24, please retarget it accordingly (to 2.24).

from Bug 376541 - Frédéric Buclin "Most of the time, we use saved searches, so we already know the parameters used. No need to redisplay them all the time." this certainly must depend on the individual, or type of user, because I almost never use saved searches, even though I have many defined for occasional use.

I'll probably do this after i finish bug 390831 which creates a generalize_query thing. That only works for the non boolean charts stuff. jesse: could you possibly explain what your expected results are for boolean charts? are you fine w/ them not being mentioned? they're considerably more complicated (there's no requirement about order in bugzilla query urls). Also, would you prefer links or checkboxes? I'm currently using links (and that most closely matches w/ the description above), but it's trivial to instead do: <tr><td>Reporter<td><input type=checkbox value="timeless@bemail.org" id="reporter"><td>timeless@bemail.org</tr>

Looks like this was already implemented in bug 463002.