150969 - don't let users query for "CC"/"Commenter" and other roles

Status: RESOLVED WORKSFORME

(Bugzilla :: Query/Bug List, defect)

Description

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

A bug in MySQL causes queries for "CC"/"Commenter" and other roles to time out,
yet the query interface continues to allow users to run those queries (and the
defaultquery parameter even defines such a query).  We should make it impossible
(or as hard as possible) to run such queries until the MySQL bug is fixed or we
work around it.

Comment 1

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

Attachment: patch v1: fixes problem

Comment 2

[Bradley Baetz (:bbaetz)]

Exact matches for cc seem not to trigger this, because we do a secondary
dbidtoname first, so the profiles table isn't in the query.

Comment 3

[Boris 'pi' Piwinger]

*** Bug 150965 has been marked as a duplicate of this bug. ***

Comment 4

[Hixie (not reading bugmail)]

If there's any chance that we could limit the block to the cases that don't
work, that would kick ass... I've been using "exact match" against reporter/qa/cc/
assignee for months in my most frequently used query, and I really need it.

Comment 5

[Bradley Baetz (:bbaetz)]

named queries bypass this check, it appears.

Your check is also wrong, anyway. CC/longdesc is OK with assignee/reporter/qa,
isn't it? Its just cc+longdesc which have the issue. At least for exact matches.

Comment 6

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

Attachment: patch v2

>CC/longdesc is OK with assignee/reporter/qa, isn't it?

No, longdesc + anything doesn't return results.  exact CC + other things,
however, does, so here's a patch that lets people make exact searches on CC +
other fields.  This patch also parameterizes the check so installations with
small databases can disable it.

Comment 7

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

Attachment: patch v3: corrected version of patch v2

The last patch missed defparams.pl.  This one includes it.

Comment 8

[Akkana Peck]

<metoo>
I also used to search for reporter/cc or assigned/cc quite often, and seldom
noticed a problem with it (even doing substring/ignorecase searches).  Sure,
sometimes it took a long time or timed out, but that's true of any bugzilla search.

I don't mind limiting to exact substring match, if that's what it takes (though
I don't understand why the regression, since it used to be allowed and usually
worked -- any chance the mySQL bug will get fixed any time soon?)

I really miss these searches, and the new bugzilla makes it especially annoying
because it pre-selects fields incompatible with cc in both of the email groups,
so if you want to search for someone in cc, you first have to deselect something
or you get the error page.  If we can't get mixed searches, how about not
preselecting anything on at least one of the email fields, and letting users
decide what they want to search for?

Comment 9

[Bradley Baetz (:bbaetz)]

Comment on attachment 87600 [details] [diff] [review]
patch v3: corrected version of patch v2

Yeah, but we really should be filing a bug with the mysql people - see bug
151817, where the sort order makes a difference.

However, you need to check that trim($FORM{'foo'}) is empty, rather than just
checking the form value directly.

Comment 10

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

Ok, I've removed the cc combination checks on the b.m.o stage installation:

http://mothra.mozilla.org/webtools/bugzilla-test/

Try a query on that installation (NOTE: the installation is running against the
*live* version of the Bugzilla database; don't enter "test" data), and let me
know if the query does what you expect and how long it takes to run.

Comment 11

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

Attachment: patch v4: review fixes1

Uses trim, doesn't restrict cc queries.

Comment 12

[Joel Peshkin]

Now that the underlying problem is fixed, this does not need to be.

(Bug 127200 fixed this)