Searching for commentor or owner returns fewer results then just searching for commentor

RESOLVED FIXED in Bugzilla 2.18

Status

()

P3
normal
RESOLVED FIXED
15 years ago
6 years ago

People

(Reporter: kniht, Assigned: bugreport)

Tracking

2.17.7
Bugzilla 2.18
Dependency tree / graph
Bug Flags:
approval +

Details

Attachments

(1 attachment)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630 Galeon/1.3.8
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630 Galeon/1.3.8

If you select within the 'Email and numbering' section both the commenter and
bug owner checkboxes and a name to search you will get fewer results then if you
just had the commenter checkbox selected.  The example I tried was in
landfill/tip with 'contains' and the string 'justdave'; with both boxes checked
I get 50 bugs while with just commenter checked I get 529 bugs matching.  I
would expect to have the same or more bugs when both boxes are checked.

Reproducible: Always
Steps to Reproduce:
(Reporter)

Updated

15 years ago
Version: unspecified → 2.17.7
(Assignee)

Comment 1

15 years ago
This problem appears to be the result of some strange special handling of
longdescs in Search.pm

In the section ...  
 if ($params->param("emaillongdesc$id")) {
     if (my $list = $self->ListIDsForEmail($type, $email)) {

longdescs gets joined in and the resulting IS NOT NULL gets added to wherepart,
so it gets ANDED in.  That section whould be removed and instead, this should
work just like the cclist... (by adding longdesc right into the code below)

        foreach my $field ("assigned_to", "reporter", "cc", "qa_contact") {
            if ($params->param("email$field$id")) {
                push(@clist, $field, $type, $email);
            }

That would be just fine, but the general code down below for longdescs does not
include the ListIDsForEmail optimization so, it should work but be extremely
slow. So, the ListIDsForEmail optimization should be ported to the  
"^long_?desc," handler.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 2

15 years ago
One workaround appears to be to search by 'matches regexp' instead of 'contains'
or 'is'.  Another is to search for the commenter on a separate search.
(Assignee)

Comment 3

15 years ago
Created attachment 149323 [details] [diff] [review]
v1
(Assignee)

Updated

15 years ago
Priority: -- → P3
Target Milestone: --- → Bugzilla 2.18
(Assignee)

Updated

15 years ago
Blocks: 226434
(Assignee)

Updated

15 years ago
Attachment #149323 - Flags: review?
Comment on attachment 149323 [details] [diff] [review]
v1

>+                 push(@supptables, "LEFT JOIN longdescs $table ON $table.bug_id = bugs.bug_id $extra AND $table.who IN ($list)");

MySQL docs say:

---snip---
You should generally not have any conditions in the ON part that are used to
restrict which rows you want in the result set, but rather specify these
conditions in the WHERE clause. There are exceptions to this rule.
---snip---

I can't find a list of what those exceptions are though.

However, there's lots of places this syntax is used in Search.pm, and if we fix
it, we should fix them all, and that's another bug.

So r=justdave
Attachment #149323 - Flags: review? → review+
Flags: approval+
(Assignee)

Comment 5

15 years ago
checked in
Status: NEW → RESOLVED
Last Resolved: 15 years ago
Resolution: --- → FIXED
Assignee: justdave → bugreport
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.