Closed
Bug 298716
Opened 19 years ago
Closed 14 years ago
Search string prefix corresponding to any match function causes error
Categories
(Bugzilla :: Query/Bug List, defect, P2)
Tracking
()
RESOLVED
WORKSFORME
People
(Reporter: lindyboi, Assigned: timeless)
References
()
Details
Attachments
(1 file, 1 obsolete file)
6.97 KB,
patch
|
wicked
:
review-
|
Details | Diff | Splinter Review |
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.8) Gecko/20050511 Firefox/1.0.4 Searching on comment or subject starting with the string "matches" fails miserably Reproducible: Always Steps to Reproduce: 1. Visit a bugzilla search page (including the enter_bug url above) 2. enter the string "Matches" 3. Click Search Actual Results: Page returns: Illegal Search The "content" field can only be used with "matches" search and the "matches" search can only be used with the "content" field. Expected Results: Given me a list of results Note this makes it moderately annoying to search for any existance of this bug by searching on the string "matches" because I can't. Here's the requested URL that showed the issue https://bugzilla.mozilla.org/buglist.cgi?format=simple&order=relevance+desc&bug_status=__open__&product=Bugzilla&content=matches
Comment 1•19 years ago
|
||
I see the same on that url.
Comment 2•19 years ago
|
||
joel, could you please investigate?
Severity: major → normal
OS: Windows XP → All
Hardware: PC → All
Comment 3•19 years ago
|
||
Happens on tip too. All you need to do is search for a summary of "matches blah"
Status: UNCONFIRMED → NEW
Ever confirmed: true
Comment 4•19 years ago
|
||
This is probably pretty fundamental in Search.pm and has been around for a while. I'm suprised that it has gone this long undetected. The function im Search.pm being triggered is this... ",matches" => sub { ThrowUserError("search_content_without_matches"); }, So, I tried searching for a summary containign "lessthan" and got an sql error.
Severity: normal → major
Priority: -- → P2
Summary: Search string prefix "matches" causes error → Search string prefix corresponding to any match function causes error
Target Milestone: --- → Bugzilla 2.20
Version: unspecified → 2.19.3
Updated•19 years ago
|
Comment 5•19 years ago
|
||
I believe I'm seeing a variant of this. Searching bugzilla for the summary "regexp test" returns no bugs, but searching for "Regexp test" or "test regexp" both return the same 5 bugs. This is with the summary search set to "contains all of the words/strings"
Comment 6•19 years ago
|
||
I think it is getting to be time for Search.pm to start to take a list of arguments rather than playing with commas. Naturally, there are many implications of this so it will take a while.
Comment 7•18 years ago
|
||
Only security and dataloss fixes will be accepted on the 2.20 branch.
Severity: major → normal
Target Milestone: Bugzilla 2.20 → Bugzilla 2.22
Updated•17 years ago
|
Target Milestone: Bugzilla 2.22 → Bugzilla 3.0
Assignee: query-and-buglist → timeless
Status: NEW → ASSIGNED
Attachment #275395 -
Flags: review?(bugreport)
Comment 9•17 years ago
|
||
Comment on attachment 275395 [details] [diff] [review] trivial This breaks everything that does operations like.... $funcsbykey{",$t"}->();
Attachment #275395 -
Flags: review?(bugreport) → review-
Assignee | ||
Comment 10•17 years ago
|
||
Attachment #275395 -
Attachment is obsolete: true
Attachment #275647 -
Flags: review?(bugreport)
Updated•16 years ago
|
Target Milestone: Bugzilla 3.0 → ---
Comment 11•15 years ago
|
||
Comment on attachment 275647 [details] [diff] [review] 0 or more I'm sorry but this is too badly bitrotten by bug 399371. >Index: Bugzilla/Search.pm >=================================================================== >- my $deadlinefrom; >+ my $deadlinefrom; Please, there's no reason for doing indentation fixes in this same patch. This change is already complicated enough. >@@ -422,6 +422,7 @@ >+ my $firstfield = '^[^,]*'; I'd say using this variable only complicates funcdefs more than it saves. Does this need to be this complicated? Would using something like |^,matches| work for all "any field using this type" entries in funcdefs?
Attachment #275647 -
Flags: review?(bugreport) → review-
Comment 13•14 years ago
|
||
This is fixed with the death of funcdefs in Bugzilla 4.0.
Status: ASSIGNED → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•