Allow users to tag bugs from the buglist




Query/Bug List
17 years ago
3 years ago


(Reporter: xyzzy, Unassigned)


(Depends on: 1 bug)

Dependency tree / graph




(3 attachments)



17 years ago
Does anyone else have queries that are really just static lists?

It would be nice to be able to save the results of a query into a fixed list
(basically just the bug numbers) that could be stored, like a query is.  This in
itself may not sound like much, but here are some of the reasons I see for it:

1) Less taxing on the database for these static lists.
2) Allows independent customization of queries and buglists, so specialized
fixed lists (buglists) could be developed.
3) Makes it easy to generate a query from a buglist.

I have found myself wanting #3 on many occasions, and I believe that #2 would
help allow lists like a "favorites" list for easy tracking of fixed sets of
bugs, possibly with a text field for easy addition or deletion from this fixed list.

Buglists could be "attached" to queries, as a "snapshot" of the query at a point
in time, and this would allow for comparative queries, like find all bugs
matching this query that weren't found by this query yesterday.

I'm sure others can think of a lot more uses for this, too.
The way I would do this is to introduce personal keywords.  This is more
flexible since you can add and remove bugs from it.  You could add all bugs to
the query by bulk change.

This might require fixing bulk changes to send out only one mail though.

See also bug #74258.

Comment 2

17 years ago
Personal keywords might be a good workaround for this, but don't address the
root problem because of the performance and customization issues I already
mentioned.  After all, a query against a keyword is still a query, a more
general, yet heavyweight version of the buglist abstraction.
I like the idea of storing a list of bug numbers for the query result.  I saw
somewhere someone was listing that they wanted buglists to change color when
there were changes in them.  If we have a static list of bug IDs stored, this
would be a very fast query to determine because you simply retrieve the last
change timestamp off the bugs in that list.

Comment 4

17 years ago
Maybe I'm mistaken, but I think this is already possible:

1. Go to .
2. Type ``crash'' in the QuickSearch textbox, hit return.
3. Click on the _second_ BugID in the resulting list.
4. Click on the "Show List" link.
5. Click on "Edit this query".
6. Choose "Remember this query, and name it:", type `crash1'
7. Click "Submit query"
8. Go to .
9. Choose "Load the remembered query:", select `crash1'
10. Click "Submit query"
11. Verify in the resulting URL that it contains the bug numbers,
    or verify in the query form that "Only bugs numbered" is selected, and the
    list of bug numbers is there.

Alternatively, run the stored query and check the result.

Or, you can coninue after step 5. like this:

6. Manually replace "query" with "buglist" in the browser's url field.
7. Hit return to load the modifed url.

Of course, this would be more usable if the "Show list" link from step 4 was
already on the buglist page, so that you could omit step 3.
Are you proposing we store the entire bug list in one field in the database? 
That might be slightly better perf but I'm not sure it's worth it.  I think a
better way to deal with changing queries would be opting-into the feature on
your stored queries.

As for workaround, I'd consider storing bug lists to be the workaround. 
Personal keywords are more flexible and clean.

And yes, you can already store a query that is a static list, although you can't
generate it from a bug list.  I guess it wouldn't be very difficult to do that,
but I don't think that's as extensive as you intend this to be.

I guess it's a valid proposal to be able to attach a bug list to a stored query
so you can view what has changed since you last updated it, but it sounds like
you're asking for more than that.

Comment 6

17 years ago
> Are you proposing we store the entire bug list in one field in the database? 

I don't know all of the specifics, especially relating to the database, but this
is a feature request, not a design spec, so if I seem to be asking for that, it
may be that I don't understand database constraints very well.

The way I see it, buglists would get stored similarly to queries.  If queries
are stored as a field, then buglists would also be a field.  While this may seem
 like a lot more data, I don't see that it is.  Storing the same query
(including specific bug numbers explicitly), would require the same/slightly
more space, albeit in the existing query field.

> That might be slightly better perf but I'm not sure it's worth it.

I cannot guess as to whether or not the performance is worth it.  I will only
say that performance was not the reason I requested this, just a happy
coincidence!  I would like to hear more about your opting-in approach, however.

> As for workaround, I'd consider storing bug lists to be the workaround. 
> Personal keywords are more flexible and clean.

With the right interfaces, bug numbers themselves can essentially disappear to
the end-user entirely, making them equally clean, IMHO.  Bug numbers would
presumably be easier to query for than any keyword, as they are unique (primary
key?) and ordered, and no substring matching would be needed.  If keywords are
more flexible, then I am overlooking something.

> but I don't think that's as extensive as you intend this to be.

No, but it's a good start.  It is frustrating to me that a buglist is only
obtained via a query.  I find buglists useful in and of themselves, and want
them to have a life of their own.  In doing this, though, I want to make sure we
build the right bridges...

Comment 7

17 years ago
> [...] a static list, although you can't generate it from a bug list. 

My comment clearly shows that you _can_ generate a static list from a bug list
(though it takes a few more clicks than it would take in a perfect world).

Comment 8

17 years ago

I believe the distinction we are making is *automatic* generation of these bug
lists (by clicking a link, making selection, etc.).  I know it can be done by
methods like the one you gave, in fact that's what I do right now!  ;)  It's
just that an 11-step procedure is a bit tedious on dialup.

Comment 9

17 years ago
Created attachment 46610 [details] [diff] [review]
fix: add a link to buglist.cgi that generates a static list
I have attached my proposal to eliminate step 3. You can view this patch in
action at the url in the URL field, together with the patch from bug 83053.

What am I missing here?


17 years ago
Keywords: patch, review
Target Milestone: --- → Bugzilla 2.16

Comment 11

17 years ago
Moving to new Bugzilla product
Assignee: justdave → endico
Component: Bugzilla → Query/Bug List
Product: Webtools → Bugzilla
Version: Bugzilla 2.13 → 2.13
"Turn this into static bug list"

I'm not sure if this is the right wording. How about "Make this exact list of
bugs bookmarkable." When you click it, it does exactly that.

However, for long buglists, won't we hit URL length problems? It'll also add to
the download time. There needs to be a check for this. What's the max length of
a URL?


Comment on attachment 46610 [details] [diff] [review]
fix: add a link to buglist.cgi that generates a static list

marking needs-work per Gerv's comment.  I agree with him.

I really like this idea though.  I believe the maximum length limit in a URL is 
1024 characters.  It should be easy enough to check this.  After generating
$staticurl, just check the length of it, and if it's < 1000 go ahead and show 
the link.
Attachment #46610 - Flags: review-
Download time shouldn't be much of an issue since the same list is already
transmitted somewhere on the page with ":" instead of "," IIRC.

Feel free to take over the fix and drive it to completion.
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 16

16 years ago
Created attachment 62315 [details] [diff] [review]
sends static bug list to query.cgi and editlist.cgi

Comment 17

16 years ago
Created attachment 62316 [details]
editlist.cgi allows custom reduction of static lists

editlist.cgi takes a list of bug ids, and allows custom filters to be applied
to the list.  These lists can be then saved as a named query, shown as a bug
list, or have additional filters applied.  Filters provided are 'Remove
blocked' and 'Show blocked', which possibly solves bug 103866.
The main benifit of static lists is they can be dis-engaged from
query.cgi/buglist.cgi, which are sufficiently complex to scare any implementor
/ administrator away from creating site based custom queries.
Reassigning to patch author.
Assignee: endico → zeroJ


15 years ago
Blocks: 75488


15 years ago
Summary: [RFE] Separate queries and buglists → Separate queries and buglists
enhancements without current patches are being pushed to 2.20
Target Milestone: Bugzilla 2.18 → Bugzilla 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.
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22


12 years ago
Depends on: 313020

Comment 21

12 years ago
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
Target Milestone: Bugzilla 2.22 → Bugzilla 2.24

Comment 22

12 years ago
*** Bug 316911 has been marked as a duplicate of this bug. ***

Comment 23

12 years ago
We can now add individual bugs to "lists of bugs", see bug 313020. The next step is to use this new feature to add bugs from the buglist itself.

My idea is to have one checkbox per bug. You can then select the ones you want to add to some given list. This will be done for 2.24.
Assignee: jayvdb → LpSolit


12 years ago
Assignee: LpSolit → query-and-buglist
QA Contact: mattyt-bugzilla → default-qa

Comment 24

12 years ago
Please leave this bug assigned to me.
Assignee: query-and-buglist → LpSolit

Comment 25

11 years ago
I think bug 118805 is a duplicate of this one (counting in the possibility of sharing saved searches (bug 69000))


11 years ago
Target Milestone: Bugzilla 3.0 → Bugzilla 3.2

Comment 26

11 years ago
I'd suggest an AJAX field that comes up where you can type in tags for a bug. It can just be a link saying "tag".
Blocks: 372023
No longer blocks: 75488
Priority: -- → P1
Summary: Separate queries and buglists → Allow users to tag bugs from the buglist


10 years ago
Duplicate of this bug: 400396


10 years ago
Priority: P1 → P3


10 years ago
Target Milestone: Bugzilla 3.2 → Bugzilla 4.0


10 years ago
Assignee: LpSolit → guy.pyrzak


6 years ago
Duplicate of this bug: 228180


6 years ago
Depends on: 616191

Comment 29

5 years ago
We are going to branch for Bugzilla 4.4 next week and this bug is too invasive or too risky to be accepted for 4.4 at this point. The target milestone is set to 5.0 which is our next major release.

I ask the assignee to reassign the bug to the default assignee if you don't plan to work on this bug in the near future, to make it clearer which bugs should be fixed by someone else on time for 5.0.
Target Milestone: Bugzilla 4.4 → Bugzilla 5.0


5 years ago
Depends on: 791584


4 years ago
Assignee: guy.pyrzak → query-and-buglist


3 years ago
Target Milestone: Bugzilla 5.0 → ---
You need to log in before you can comment on or make changes to this bug.