217071 - can't search for two cc list members - Software Error

Status: RESOLVED DUPLICATE of bug 180980

(Bugzilla :: Query/Bug List, defect)

Description

[Christian :Biesinger (don't email me, ping me on IRC)]

On http://bugzilla.mozilla.org/query.cgi:
Search for "CC list member is" "[e-mail]", and also search for "CC list
member is" "[e-mail]".
(or click the url in this url field)

You get:

Please stand by ...
Content-type: text/html
Software error:

SELECT bugs.bug_id, bugs.bug_severity, bugs.priority, bugs.rep_platform,
map_assigned_to.login_name, bugs.bug_status, bugs.resolution,
bugs.target_milestone, bugs.short_desc FROM bugs, profiles AS map_assigned_to
LEFT JOIN cc cc_ ON bugs.bug_id = cc_.bug_id AND cc_.who IN(15661) LEFT JOIN cc
cc_ ON bugs.bug_id = cc_.bug_id AND cc_.who IN(27539) LEFT JOIN bug_group_map 
ON bug_group_map.bug_id = bugs.bug_id  AND bug_group_map.group_id NOT IN
(2,9,10)  LEFT JOIN cc ON cc.bug_id = bugs.bug_id AND cc.who = 15661  WHERE
bugs.assigned_to = map_assigned_to.userid AND (bugs.bug_status IN
('NEW','ASSIGNED','REOPENED')) AND (cc_.who IS NOT NULL) AND (cc_.who IS NOT
NULL) AND ((bug_group_map.group_id IS NULL)    OR (bugs.reporter_accessible = 1
AND bugs.reporter = 15661)     OR (bugs.cclist_accessible = 1 AND cc.who IS NOT
NULL)     OR (bugs.assigned_to = 15661) OR (bugs.qa_contact = 15661) ) GROUP BY
bugs.bug_id ORDER BY bugs.priority,bugs.bug_id : Not unique table/alias: 'cc_'
at globals.pl line 284.

For help, please send mail to the webmaster ([e-mail]), giving this
error message and the time and date of the error.

Comment 1

[Dave Miller [:justdave]]

Mine.

Zippy's QA folks found this one and we fixed it already in theirs.  I'll see if
I can port the patch out.

Comment 2

[Dave Miller [:justdave]]

Attachment: Patch

Patch applies to Bugzilla without modification. :)

The basic idea here is that @supptables gets screened for duplicates when it's
compiled into the final query.	By including the data we were searching for in
the join condition, this made the two different @supptable entries appear to be
unique, even though they were part of the same "chart" (the upper part of the
form in this case).  By moving the search data to the @wherepart the @supptable
entries for both look the same, and the second one is properly removed during
the duplicate screening.

Comment 3

[Bradley Baetz (:bbaetz)]

Comment on attachment 130318 [details] [diff] [review]
Patch

Nope, this doesn't work. consider a query with OR and a cc query. If its in
@wherepart, then we'll fail to match even though we really could.

This patch effectively reverts the patch in bug 139759.

Comment 4

[Dave Miller [:justdave]]

The primary change in bug 139759 was to change the implicit inner join to a left
join.  The left join will still produce a null if there's no matches, even if
the data comparison isn't part of the join, so the OR should still work...

Comment 5

[Dave Miller [:justdave]]

The steps to reproduce given here fail to reproduce the error, either with or
without this patch, on landfill.

All iterations of AND, OR, and extra chart in the boolean chart area with CC is
equal to, as well as the two email boxes on the form, provide the expected
results, both with and without this patch.

So apparently something else somewhere along the line has fixed this as a side
effect.

b.m.o will get it in a couple weeks when the upgrade.

Comment 6

[Dave Miller [:justdave]]

OK, this was specifically fixed.  Found the original bug.  Will re-resolve as a
dupe shortly.

Comment 7

[Dave Miller [:justdave]]

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