179238 - Searching by commenter (longdesc) is ignored if you do "exact" or "contains"

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect)

Description

[Gervase Markham [:gerv]]

In bug 179176, Andrew Schultz says:

"searching by commenter (longdesc) seems to be ignored if you do "exact" or
"contains".  "matches regexp" seems to work."

This bug is to track that issue. [e-mail] - just for future
reference, please file bugs for issues rather than adding comments. Thanks :-)

Gerv

Comment 1

[Gervase Markham [:gerv]]

This works fine for me:

http://bugzilla.mozilla.org/buglist.cgi?product=Bugzilla&component=Reporting%2FCharting&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&emaillongdesc1=1&emailtype1=exact&email1=gerv%40mozilla.org&cmdtype=doit

produces 28 bugs.

Gerv

Comment 2

[Andrew Schultz]

right, but I would assume that you were a "commenter" on all those bugs. 
removing the email criteria still returns 28 bugs.

here's the type of search I was using.   Reopened bugs that were changed
yesterday or today.  28 of them, but I haven't commented on any of them.

http://bugzilla.mozilla.org/buglist.cgi?bug_status=REOPENED&emaillongdesc1=1&emailtype1=exact&email1=ajschult%40eos.ncsu.edu&changedin=1

Comment 3

[John Levon]

Gerv, if you want new bugs instead of comments, I suggest that
you don't have this banner text after upgrades :

Note: Bugzilla has been upgraded. Regressions are being tracked in meta-bug
179196. If you think you have found a regression, report it in that bug. 

A little unfair on Andrew I believe ;)

Comment 4

[Dave Miller [:justdave]]

Gerv, reference comment #0, for the record, the banner at the top says "If you
think you have found a regression, report it in that bug."  Andrew just did as
he was told :)

Comment 5

[Andrew Schultz]

Ya, I was contemplating filing a new bug, but figured I would follow
directions... :)

Comment 6

[Stefan [:stefanh]]

And this search http://bugzilla.mozilla.org/buglist.cgi?
short_desc_type=allwordssubstr&short_desc=&product=mozilla.org&long_desc_type=su
bstring&long_desc=&bug_file_loc_type=allwordssubstr&bug_file_loc=&status_whitebo
ard_type=allwordssubstr&status_whiteboard=&keywords_type=allwords&keywords=&bug_
status=NEW&emaillongdesc1=1&emailtype1=exact&email1=[e-mail]&em
ailassigned_to2=1&emailreporter2=1&emailqa_contact2=1&emailtype2=exact&email2=&b
ugidtype=include&bug_id=&votes=&changedin=&chfieldfrom=&chfieldto=Now&chfieldval
ue=&cmdtype=doit&order=Reuse+same+sort+as+last+time&field0-0-0=noop&type0-0-
0=noop&value0-0-0=

returns 435 bugs... 

Comment 7

[John Levon]

Yep, happens for me too, email -is- [e-mail] returns
all open bugs, instead of ones I commented on. when I go back to
the search page, the email field has been wiped out.

Comment 8

[R.K.Aa.]

CC bbaetz - this is the bug we talked about

Comment 9

[R.K.Aa.]

<bbaetz> can you file a blocker bug, blocking 'bmo-regressions'

Raising severity. I use the address fields in almost half my searches

Comment 10

[Andrew Schultz]

note that "regexp" searches still work and is a viable workaround for "is" and
"contains" (probably a little slower, but...)

Comment 11

[Bradley Baetz (:bbaetz)]

rkaa gave me sql last night from the buglist

The problem is that we join to the longdescs table, but we don't add a
constraint to the where clause which sort of defeats the purpose. I'll look into
this in a bit.

Comment 12

[Bradley Baetz (:bbaetz)]

bugzilla, not m.o

Joel, this is your regression:

push(@supptables, "LEFT JOIN longdescs $table ON bugs.bug_id = $table.bug_id AND
$table.who IN($list)");
                push(@clist, "$table.who",'isnotnull');

@clist only has two items, so we bail out.

I'm going to drop the isnotnull branch you added, and just push to wherepart
manually. Or I could add a dummy item as the third element, but I think that the
first is cleaner.

Comment 13

[Bradley Baetz (:bbaetz)]

Attachment: fix

I also have to push something to @ctype so that we don't trigger the error a
few lines down

Comment 14

[Gervase Markham [:gerv]]

I'm getting a lot of msqld-watcher mails at the moment. This could be the cause
- the below query probably takes a lot of work.

7573   bugs   localhost   shadow_bugs   Query     184     Sorting result  
SELECT bugs.bug_id, bugs.bug_severity, bugs.priority, bugs.rep_platform,
       map_assigned_to.login_name, bugs.bug_status, bugs.resolution,
       bugs.short_desc 
 FROM bugs, profiles AS map_assigned_to 
   LEFT JOIN longdescs longdescs_ ON bugs.bug_id = longdescs_.bug_id 
         AND longdescs_.who IN(73509) 
   LEFT JOIN bug_group_map  ON bug_group_map.bug_id = bugs.bug_id  
   LEFT JOIN cc ON cc.bug_id = bugs.bug_id 
         AND cc.who = 73509  
WHERE bugs.assigned_to = map_assigned_to.userid 
  AND 1 = 1
  AND ((bug_group_map.group_id IS NULL)    
       OR (bugs.reporter_accessible = 1 AND bugs.reporter = 73509)     
       OR (bugs.cclist_accessible = 1 AND cc.who IS NOT NULL)     
       OR (bugs.assigned_to = 73509) 
       OR (bugs.qa_contact = 73509) ) 
GROUP BY bugs.bug_id 
ORDER BY bugs.bug_id   

Gerv

Comment 15

[Bradley Baetz (:bbaetz)]

gerv: yeah, this degrades to a whole-db search if you don't ahve any extra
conditions (not that a query for 'all bugs I've commented on, ever' if going to
be fast, mind you)

Comment 16

[Myk Melez [:myk] [@mykmelez]]

Comment on attachment 105724 [details] [diff] [review]
fix

This works as expected.  Only one review needed, so cancelling the second. 
r=myk, a=myk

Comment 17

[Bradley Baetz (:bbaetz)]

Fixed.

Comment 18

[Bradley Baetz (:bbaetz)]

... which means fied in cvs, not bmo, although myk was going to fix this one
manually RSN, mainly becuase of the perf hit when effectivl;y trying to retreive
all bugs.

Comment 19

[Bradley Baetz (:bbaetz)]

'mattyt' != our mattyt, sorry [e-mail]

Comment 20

[Bradley Baetz (:bbaetz)]

'mattyt' != our mattyt, sorry [e-mail]