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




17 years ago
6 years ago


(Reporter: myk, Assigned: endico)




(1 attachment, 3 obsolete attachments)



17 years ago
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.


17 years ago
Blocks: 75488

Comment 1

17 years ago
Created attachment 87280 [details] [diff] [review]
patch v1: fixes problem
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.
*** Bug 150965 has been marked as a duplicate of this bug. ***
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.
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

17 years ago
Created attachment 87599 [details] [diff] [review]
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.
Attachment #87280 - Attachment is obsolete: true

Comment 7

17 years ago
Created attachment 87600 [details] [diff] [review]
patch v3: corrected version of patch v2

The last patch missed  This one includes it.
Attachment #87599 - Attachment is obsolete: true

Comment 8

17 years ago
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 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.
Attachment #87600 - Flags: review-

Comment 10

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

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

17 years ago
Created attachment 90684 [details] [diff] [review]
patch v4: review fixes1

Uses trim, doesn't restrict cc queries.
Attachment #87600 - Attachment is obsolete: true

Comment 12

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

(Bug 127200 fixed this) 
Last Resolved: 16 years ago
Resolution: --- → WORKSFORME
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.