253131 - Allow reporting of a bug directly against a product in the bug list

Status: RESOLVED DUPLICATE of bug 328667

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

Description

[Dave Neary]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.8
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040614 Firefox/0.8


If I am querying for bugs againsta  single product, I should be able to create a
bug directly against this product from the bug list. 

If there are a lot of products, taking out that extra step can make things
easier for people who aren't familiar with bugzilla (you can provide a link
direct to the bugs open againsta  product, and there is then a link to report a
bug against that product in the resulting page).

Dave.

Reproducible: Always
Steps to Reproduce:

Comment 1

[Dave Neary]

Attachment: Patch against buglist.cgi

This patch takes bugproducts out of the dotweak conditional since it's useful
for us too.

Comment 2

[Dave Neary]

Attachment: Patch against list.html.tmpl

This patch adds the link to the bottom of list.html while checking that there
is only one product in the buglist.

Comment 3

[Dave Neary]

Patches are against a stock 2.16.2 install. I hope things haven't changed so
substantially that they are invalid now.

Comment 4

[Joel Peshkin]

If we decide to do this, it should also preselect the other fields in the bug
form to match what was asked in the main section of the advanced search form. 
The same logic that makes it nice to do this for Product applies to component,
op_sys, etc...

Comment 5

[Dave Neary]

I missed a problem in this patch. It will only work if the product is in the
displayed columns (otherwise, since product is added to the query only when
dotweak is true, we don't have the product info in bugs at all).

I guess that product should also be added to the query string all the time, even
if it is not in the display columns, for this to work all the time.

Cheers,
Dave.

Comment 6

[Joel Peshkin]

Actually, if you do as I suggest in comment 4, this becomes a function of the
search criteria rather than the results returned and the issue in comment 5
should not be an issue.

Comment 7

[Dave Neary]

How can I get at the search criteria in the buglist? And does this also work if
I am re-getting a previous list?

Comment 8

[Joel Peshkin]

buglist.cgi digs up the actual query being run and passes that to Search.  By
the time that...

my $search = new Bugzilla::Search('fields' => \@selectnames,
                                  'params' => $params);

is run, the $params object contains the same param list you see in the URL when
editing the query, even in the case of a named query. $params->param('product')
would contain list of the products being selected.

In Bugzilla/Search.pm, you can see that this is digested as ,,,

    my @legal_fields = ("product", "version", "rep_platform", "op_sys",
                        "bug_status", "resolution", "priority", "bug_severity",
                        "assigned_to", "reporter", "component",
                        "target_milestone", "bug_group");

    foreach my $field ($params->param()) {
        if (lsearch(\@legal_fields, $field) != -1) {
            push(@specialchart, [$field, "anyexact",
                                 join(',', $params->param($field))]);
        }
    }

If you were to go through a subset of these fields and make a list of the fields
that were restricted to one value, then you would pass those to your enter_bug link.

I am making the assumption here that this is intended to be used where a user
searches for a known bug and, not finding it, enters one.  That being the case,
I suspect that nearly all of these fields are valid for that. 

Comment 9

[Joel Peshkin]

Comment on attachment 154382 [details] [diff] [review]
Patch against list.html.tmpl

Also, 2 points ont he patches....
1) You should combine the whole thing into one patchfile. That can be done by
diffing against your cvs checkout using cvs diff -u or by concatenating the
patchfiles.  It makes it much easier (possible, really) to reivew.

2) You need to FILTER  the URL to escape characters that dont belong in a URL.

Comment 10

[Dave Neary]

Hi,

Sorry Joe - as I said right up front, the diffs were against 0.16.something, not
CVS. And I'm afraid I don't know how to filter the URL in the templates. Could
you point me to another example where this is done?

Dave.

Comment 11

[Dave Neary]

Joel, not Joe. Excuse the typo :)

Dave.

Comment 12

[GavinS]

(In reply to comment #10)
> And I'm afraid I don't know how to filter the URL in the templates. Could
> you point me to another example where this is done?

There is some info about filtering in the Bugzilla Developer Guide on
www.bugzilla.org. In your diff, I think you need [% product FILTER url_quote %]
for when you create the URL, and [% product FILTER html %] for the actual text
of the link.

I'm not sure about where the urlquerypart comes from, and what it contains, so I
I'm not commenting on the filtering needs for that one.

Comment 13

[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 14

[Olav Vitters]

I consider this a dupe of bug 328667. Later the idea was changed a bit (even tranferring OS data etc), but bug 328667 implements exactly what was initially requested.

*** This bug has been marked as a duplicate of 328667 ***