95722 - Allow users to tag bugs from the buglist

Status: NEW

(Bugzilla :: Query/Bug List, enhancement, P3)

Description

[xyzzy]

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.

Comment 1

[Matthew Tuck [:CodeMachine]]

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

[xyzzy]

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.

Comment 3

[Dave Miller [:justdave]]

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

[Andreas Franke (gone)]

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

1. Go to bugzilla.mozilla.org .
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 http://bugzilla.mozilla.org/query.cgi .
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.

Comment 5

[Matthew Tuck [:CodeMachine]]

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

[xyzzy]

> 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

[Andreas Franke (gone)]

> [...] 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

[xyzzy]

Andreas,

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

[Andreas Franke (gone)]

Attachment: fix: add a link to buglist.cgi that generates a static list

Comment 10

[Andreas Franke (gone)]

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?

Comment 11

[Jacob Steenhagen]

Moving to new Bugzilla product

Comment 12

[Gervase Markham [:gerv]]

"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?

Gerv

Comment 13

[Dave Miller [:justdave]]

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.

Comment 14

[Andreas Franke (gone)]

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.

Comment 15

[Dave Miller [:justdave]]

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.

Comment 16

[John Vandenberg]

Attachment: sends static bug list to query.cgi and editlist.cgi

Comment 17

[John Vandenberg]

Attachment: 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.

Comment 18

[Andreas Franke (gone)]

Reassigning to patch author.

Comment 19

[Dave Miller [:justdave]]

enhancements without current patches are being pushed to 2.20

Comment 20

[Dave Miller [:justdave]]

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.

Comment 21

[Frédéric Buclin]

The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.

Comment 22

[Frédéric Buclin]

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

Comment 23

[Frédéric Buclin]

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.

Comment 24

[Frédéric Buclin]

Please leave this bug assigned to me.

Comment 25

[bigstijn]

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

Comment 26

[Max Kanat-Alexander]

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".

Comment 29

[Frédéric Buclin]

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.