Search string prefix corresponding to any match function causes error

RESOLVED WORKSFORME

Status

()

P2
normal
RESOLVED WORKSFORME
13 years ago
8 years ago

People

(Reporter: lindyboi, Assigned: timeless)

Tracking

Details

(URL)

Attachments

(1 attachment, 1 obsolete attachment)

6.97 KB, patch
wicked
: review-
Details | Diff | Splinter Review
(Reporter)

Description

13 years ago
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
I see the same on that url.

Comment 2

13 years ago
joel, could you please investigate?
Severity: major → normal
OS: Windows XP → All
Hardware: PC → All

Comment 3

13 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

13 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
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

13 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

13 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

11 years ago
Target Milestone: Bugzilla 2.22 → Bugzilla 3.0
(Assignee)

Comment 8

11 years ago
Created attachment 275395 [details] [diff] [review]
trivial
Assignee: query-and-buglist → timeless
Status: NEW → ASSIGNED
Attachment #275395 - Flags: review?(bugreport)

Comment 9

11 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

11 years ago
Created attachment 275647 [details] [diff] [review]
0 or more
Attachment #275395 - Attachment is obsolete: true
Attachment #275647 - Flags: review?(bugreport)

Updated

11 years ago
Target Milestone: Bugzilla 3.0 → ---
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-

Updated

8 years ago
Duplicate of this bug: 598193

Comment 13

8 years ago
This is fixed with the death of funcdefs in Bugzilla 4.0.
Status: ASSIGNED → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME

Updated

8 years ago
Duplicate of this bug: 631874
You need to log in before you can comment on or make changes to this bug.