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)

2.17.6
defect

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)
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
QA Contact: stolenclover → mattyt-bugzilla
If I change the search in attachment 144679 [details] to something other than Content,
this does not happen.

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
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??
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.
hmm. We should usefully error, after implementing the JS thing.
Target Milestone: Bugzilla 2.18 → Bugzilla 2.20
Attached patch patch - throw a sensible error (obsolete) — Splinter Review
Assignee: myk → bugreport
Status: NEW → ASSIGNED
Attachment #153959 - Flags: review?
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-
Attached patch v2Splinter Review
Attachment #153959 - Attachment is obsolete: true
Attachment #153973 - Flags: review?(jouni)
Comment on attachment 153973 [details] [diff] [review]
v2

Now you're talking.
Attachment #153973 - Flags: review?(jouni) → review+
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
checked in on both branches
Status: ASSIGNED → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
*** Bug 235816 has been marked as a duplicate of this bug. ***
QA Contact: matty_is_a_geek → default-qa
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: