Closed Bug 179238 Opened 21 years ago Closed 21 years ago
Searching by commenter (longdesc) is ignored if you do "exact" or "contains"
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. firstname.lastname@example.org - just for future reference, please file bugs for issues rather than adding comments. Thanks :-) Gerv
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
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 ;)
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 :)
Ya, I was contemplating filing a new bug, but figured I would follow directions... :)
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=NEWemail@example.com&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...
Yep, happens for me too, email -is- firstname.lastname@example.org 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.
CC bbaetz - this is the bug we talked about
<bbaetz> can you file a blocker bug, blocking 'bmo-regressions' Raising severity. I use the address fields in almost half my searches
Severity: normal → blocker
note that "regexp" searches still work and is a viable workaround for "is" and "contains" (probably a little slower, but...)
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.
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.
Assignee: myk → bbaetz
Component: Server Operations → Query/Bug List
Product: mozilla.org → Bugzilla
QA Contact: myk → mattyt
Target Milestone: --- → Bugzilla 2.18
Version: other → 2.17.1
I also have to push something to @ctype so that we don't trigger the error a few lines down
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
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)
Status: NEW → ASSIGNED
Comment on attachment 105724 [details] [diff] [review] fix This works as expected. Only one review needed, so cancelling the second. r=myk, a=myk
Status: ASSIGNED → RESOLVED
Closed: 21 years ago
Resolution: --- → FIXED
... 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.
'mattyt' != our mattyt, sorry email@example.com
'mattyt' != our mattyt, sorry firstname.lastname@example.org
QA Contact: mattyt → matty
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.