Closed
Bug 65391
Opened 24 years ago
Closed 16 years ago
Give brief summary of bug list query in buglist.cgi
Categories
(Bugzilla :: Query/Bug List, enhancement, P3)
Tracking
()
RESOLVED
DUPLICATE
of bug 463002
People
(Reporter: CodeMachine, Unassigned)
References
(Depends on 1 open bug, )
Details
Attachments
(4 files)
(deleted),
patch
|
Details | Diff | Splinter Review | |
(deleted),
text/html
|
Details | |
(deleted),
text/html
|
Details | |
(deleted),
patch
|
jouni
:
review-
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Comment 1•24 years ago
|
||
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.
Comment 2•24 years ago
|
||
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.
Updated•24 years ago
|
Summary: Give brief summary of bug list query. → Give brief summary of bug list query in buglist.cgi
Comment 3•24 years ago
|
||
I think the "Edit this query" link provides this functionality.
Comment 4•24 years ago
|
||
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.
Comment 5•24 years ago
|
||
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?
Reporter | ||
Comment 6•24 years ago
|
||
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.
Comment 7•24 years ago
|
||
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.
Reporter | ||
Comment 8•24 years ago
|
||
Well, we could do something like that. I was thinking about not polluting the
bug list so much, but maybe it doesn't matter ...
Comment 9•24 years ago
|
||
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
Comment 10•24 years ago
|
||
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.
Comment 11•24 years ago
|
||
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.
Depends on: 15809
Reporter | ||
Updated•24 years ago
|
Target Milestone: --- → Future
Reporter | ||
Updated•23 years ago
|
Severity: minor → enhancement
Comment 12•23 years ago
|
||
The rfe in bug 96120 could help a little in managing bugzilla queries. But this
is the best long-term solution.
Reporter | ||
Comment 13•23 years ago
|
||
Moving to new Bugzilla product ...
Assignee: tara → endico
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: other → 2.13
Comment 14•23 years ago
|
||
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)
Depends on: 98123
Comment 15•23 years ago
|
||
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.
Comment 16•23 years ago
|
||
Comment 17•23 years ago
|
||
Comment 18•23 years ago
|
||
Reporter | ||
Updated•23 years ago
|
Priority: -- → P3
Target Milestone: Future → Bugzilla 2.16
Comment 19•23 years ago
|
||
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.
Target Milestone: Bugzilla 2.16 → Bugzilla 2.18
Comment 20•23 years ago
|
||
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 21•23 years ago
|
||
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?
Attachment #64496 -
Flags: review-
Updated•21 years ago
|
Assignee: endico → nobody
Comment 22•21 years ago
|
||
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
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Comment 23•20 years ago
|
||
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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Comment 24•20 years ago
|
||
*** Bug 282348 has been marked as a duplicate of this bug. ***
Comment 25•19 years ago
|
||
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).
Target Milestone: Bugzilla 2.22 → ---
Updated•18 years ago
|
QA Contact: mattyt-bugzilla → default-qa
Comment 27•17 years ago
|
||
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.
Comment 28•17 years ago
|
||
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>
Depends on: 390831
Updated•16 years ago
|
Assignee: nobody → query-and-buglist
Comment 29•16 years ago
|
||
Looks like this was already implemented in bug 463002.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → DUPLICATE
You need to log in
before you can comment on or make changes to this bug.
Description
•