634 bytes, patch
|Details | Diff | Splinter Review|
849 bytes, patch
|Details | Diff | Splinter Review|
3.80 KB, text/plain
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.
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.
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.
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.
> 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...
> [...] 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).
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.
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?
Moving to new Bugzilla product
"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 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.
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.
Created attachment 62315 [details] [diff] [review] sends static bug list to query.cgi and editlist.cgi
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.
enhancements without current patches are being pushed 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.
The trunk is now frozen to prepare Bugzilla 2.22. Enhancement bugs are retargetted to 2.24.
*** Bug 316911 has been marked as a duplicate of this bug. ***
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.
Please leave this bug assigned to me.
I think bug 118805 is a duplicate of this one (counting in the possibility of sharing saved searches (bug 69000))
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".
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.