Closed
Bug 238544
Opened 20 years ago
Closed 20 years ago
bogus and totally wrong output after entering a possibly malformed search criteria
Categories
(Bugzilla :: Query/Bug List, defect, P2)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: nospam, Assigned: bugreport)
References
()
Details
Attachments
(3 files, 1 obsolete file)
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.6) Gecko/20040113 Described in Steps to Reproduce Reproducible: Always Steps to Reproduce: 1. http://bugzilla.mozilla.org/query.cgi#chart 2. just fill in "get new messages POP" in Advanced Querying Using Boolean Charts, field chosen: Content/contains all the words 3. press search and you get an empty page showing just "</p>" Actual Results: See attached query page and source of the results page showed. Maybe it's just a particular time/load issue on your server. The exact time when this was tested a few times was 21:25 MET (GMT+1)
Reporter | ||
Comment 1•20 years ago
|
||
Reporter | ||
Comment 2•20 years ago
|
||
Comment 3•20 years ago
|
||
I have a feeling this has something to do with the new fulltext search.... (I didn't know you could access it from the advanced query :)
Assignee: endico → myk
Status: UNCONFIRMED → NEW
Component: webmaster@mozilla.org → Query/Bug List
Ever confirmed: true
OS: Linux → All
Product: mozilla.org → Bugzilla
Hardware: PC → All
Target Milestone: --- → Bugzilla 2.18
Version: other → 2.17.6
Updated•20 years ago
|
QA Contact: stolenclover → mattyt-bugzilla
Assignee | ||
Comment 4•20 years ago
|
||
If I change the search in attachment 144679 [details] to something other than Content,
this does not happen.
Assignee | ||
Comment 5•20 years ago
|
||
Here we go... buglist.cgi: DBD::mysql::st execute failed: Unknown column 'bugs.content' in 'where clause' [for Statement "SELECT bugs.bug_id, bugs.bug_severity, bugs.priority, bugs.bug_status, bugs.resolution, 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 bug_group_map ON bug_group_map.bug_id = bugs.bug_id AND bug_group_map.group_id NOT IN (8,6,3,9,5,2,4,7,1) LEFT JOIN cc ON cc.bug_id = bugs.bug_id AND cc.who = 1 WHERE bugs.assigned_to = map_assigned_to.userid AND (bugs.bug_status IN ('NEW','ASSIGNED','REOPENED')) AND (INSTR(LOWER(bugs.content), 'rggr') AND INSTR(LOWER(bugs.content), 're') AND INSTR(LOWER(bugs.content), 'ergt')) AND ((bug_group_map.group_id IS NULL) OR (bugs.reporter_accessible = 1 AND bugs.reporter = 1) OR (bugs.cclist_accessible = 1 AND cc.who IS NOT NULL) OR (bugs.assigned_to = 1) OR (bugs.qa_contact = 1) ) GROUP BY bugs.bug_id ORDER BY bugs.bug_id "] at Bugzilla/DB.pm line 66, It looks like Bugzilla does not REALLY know how to search for content. Was this added to fielddefs without either teaching Search.pm about it or teaching query to exclude it?
Priority: -- → P2
Assignee | ||
Comment 6•20 years ago
|
||
More specficially, we ONLY know how to search content using the "matches" search. This makes sense since I doubt the fulltext index could handle any of the others. What's the right thing to do here, a) Throw a user-error if someone attempts to do another type of query? b) Use javascript to keep the user from selecting any of the other options with the content field? c) Other??
Comment 7•20 years ago
|
||
and the matches operator probably only works on content and none of the other fields, right? pah. Yeah, there's lots of field/operator combos that will throw errors or are guaranteed not to find anything. for Zippy we used Javascript to repopulate the operator list based on which field was selected.
Comment 8•20 years ago
|
||
hmm. We should usefully error, after implementing the JS thing.
Updated•20 years ago
|
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Assignee | ||
Comment 9•20 years ago
|
||
Assignee: myk → bugreport
Status: NEW → ASSIGNED
Assignee | ||
Updated•20 years ago
|
Attachment #153959 -
Flags: review?
Comment 10•20 years ago
|
||
Comment on attachment 153959 [details] [diff] [review] patch - throw a sensible error >Index: Bugzilla/Search.pm >=================================================================== >+ "^content," => sub { >+ ThrowCodeError("field_type_mismatch", >+ { field => $f, type => $t}); >+ }, This produces the code error "Cannot seem to handle content and equals together." which isn't very useful either. I think we should throw a user error stating that "Content field can only be searched using the 'matches' operator". This additional information would also guide the user into the right direction AND be much more friendly.
Attachment #153959 -
Flags: review? → review-
Assignee | ||
Comment 11•20 years ago
|
||
Attachment #153959 -
Attachment is obsolete: true
Assignee | ||
Updated•20 years ago
|
Attachment #153973 -
Flags: review?(jouni)
Comment 12•20 years ago
|
||
Comment on attachment 153973 [details] [diff] [review] v2 Now you're talking.
Attachment #153973 -
Flags: review?(jouni) → review+
Comment 13•20 years ago
|
||
Yeah, I realize this touches a template, but it's one less source of confusion for folks using 2.18...
Flags: approval2.18+
Flags: approval+
Target Milestone: Bugzilla 2.20 → Bugzilla 2.18
Assignee | ||
Comment 14•20 years ago
|
||
checked in on both branches
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
Comment 15•19 years ago
|
||
*** Bug 235816 has been marked as a duplicate of this bug. ***
Updated•11 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•