139759 - 'Any of: CC list member' causes problems if used with 'Any of: bug owner'

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, defect, P1)

Description

[David Ward]

It seems that if I choose 'Any of bug owner OR CC list member IS user' in the
query screen I only get back bugs that I am on the CC list for and not getting
the ones where I am the bug owner and there is nobody on the CC list.

I have net yet been able to trace the code and patch it to work correctly, but
it seems that the cause is that the join between the bugs and cc tables
eliminates any bug that does not have a user on the CC list from the result set.

Comment 1

[Bradley Baetz (:bbaetz)]

This is with CVS bugzilla? If so, I think this is me.

-> 2.16, will look at it tomorrow.

See bug 127200. I may have to partly revert that.

Comment 2

[David Ward]

Attachment: Attempt at a patch to fix the problem.

Yes, this is with the most current cvs version.

The attached patch seems to fix the problem (with limited testing).

Comment 3

[David Ward]

After reading bug 127200 it seems that it was the fix of that bug that causes
this problem, and the patch that I made will probably take things back to the
original problem that was reported there (slow searching on CC with large
databases).

The other option (that I haven't figured out how to change the code for yet) was
to move the 
  AND bugs.bug_id = cc_.bug_id
  AND cc_.who = map_cc_.userid
qualifications into the part generated by $f
  OR map_cc_.login_name = 'dward')
which would then become
  OR (map_cc_.login_name = 'dward' AND cc_.who = map_cc_.userid AND bugs.bug_id
= cc_.bug_id)

Comment 4

[Bradley Baetz (:bbaetz)]

I think that if we just make the first join a left join, then that will work.
names must be exact, but if it doesn't then having one left join will still
leave the row in.

Comment 5

[Bradley Baetz (:bbaetz)]

After speaking to myk, theres no way out of this - its valid to search for bugs
where the cc is a non-existant person as long as its OR'd with a valid constraint.
So your patch, effectively backing out bug 127200, is OK.

I'm not sure what the first part of your patch is doing, though - can you explain?

Comment 6

[Bradley Baetz (:bbaetz)]

This is a very common query which is now broken, so -> blocker

Thinking about this a bit more, what I really want is a subselect of the cc
table joined to the profiles table with an inner join, and then leftjoin the
bugs table to that. That would be a lot faster than two inner joins. Shame mysql
doesn't support those....

We could query separately, mind you, and then do an IN(1,2,....) style search,
or use temporary tables once we require mysql 3.23.

After checking this in, I'll reopen bug 127200 for 2.18, and think about this.

Comment 7

[David Ward]

Oops.  The first part should probably not have gotten into the patch I created
as it has nothing to do with the problem at hand.  It was just an attempt to try
cleaning up the query a bit as I was trying to find the problem.

map_assigned_to and map_reporter end up in the query twice, once by a hard-coded
piece at the beginning of sub GenerateSQL and again if bug owner or reporter was
checked on the query form, I was jsut trying to see if both were needed (and it
didn't look like it).

Comment 8

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

Attachment: patch v1 with first part removed

This is David Ward's patch with the first part removed.

Comment 9

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

Comment on attachment 81171 [details] [diff] [review]
patch v1 with first part removed

works, 2xr=myk.  When this is checked in, the bug it regresses should be
reopened.  David, do you have check-in privileges, or do you need someone to
check this in for you?

Comment 10

[David Ward]

Someone else needs to check this in as I do not have check-in privileges.

Comment 11

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

Checking in buglist.cgi;
/cvsroot/mozilla/webtools/bugzilla/buglist.cgi,v  <--  buglist.cgi
new revision: 1.166; previous revision: 1.165
done