View Issue Details

IDProjectCategoryView StatusLast Update
0006125mantisbtfilterspublic2015-01-02 13:13
Reportermichield Assigned Tovboctor  
PrioritynormalSeverityfeatureReproducibilityalways
Status closedResolutionwon't fix 
Product Version1.3.0-beta.1 
Summary0006125: small improvement to search filter
Description

I tried this on current CVS and it works fine.

In core/filter_api.php at line 682 (for me) add a little line:

  $c_search = str_replace(' ','%',$c_search);

this will cause a search string with spaces to become more "wildcarded" and therefore a better search.

Eventually of course, it might be nice to add some more stuff like splitting into words, and changing the order of them in the search query, which should only be a couple of lines, but this one is a good effect with a simple alteration.

TagsNo tags attached.

Activities

grangeway

grangeway

2014-10-09 17:47

reporter   ~0041506

We wouldn't add this patch to search filter for the simple reason that whilst you identify the fact it might be nice to have

"foo bar" do a search for foo or bar, equally there are times when one would want "foo bar" to do an exact match.

THerefore, suggested code change in this bug report wouldnt' be applicable.

michield

michield

2014-10-10 03:13

reporter   ~0041515

sounds like you don't search in mantis a lot. I do it daily and have so for the last 11 years.

dregad

dregad

2014-10-10 04:39

developer   ~0041518

I'm not really sure what we would really gain by this, except a loss of flexibility in text searches.

Today if you search for

  1. "foo bar", Mantis will return all bugs having both words anywhere in the text.
  2. "'foo bar'" will return bugs having the 2 words next to each other (exactly as typed)
  3. "foo -bar", will give you bugs having 'foo' but not 'bar'
  4. "foo%bar' will return bugs having the 2 words in the order provided

Implementing your suggested change would actually prevent one from using 1 and 2 (reducing them to case 4), and actually break 3.

So I actually agree with grangeway (!) here that this should be a won't fix.

grangeway

grangeway

2014-10-10 14:18

reporter   ~0041526

Damien/Michield,

I'm going to reopen this issue - my goal of cleaning up was to try and ensure that we can focus on "user issues" - so whilst I think there's no way we'd actually do what you were asking for (Damien's explanation states why).

Given the fact you've replied - i'd be really interested to get a work item that could be implemented.

So to try and turn this into something constructive:

We could never replace space with % as some people might like non-wildcarded searches -> consider that a decision

Equally, Damien's example (number 4) that you could search for foo%bar to get "foo moo bar" to match i.e. this is what you were asking for back in 2005.

Do we need:

a) A method to match "foo%bar"

b) A method to match "foo" OR "bar"

And when considering the above, given that "foo bar" should match the exact string, how would/could we implement the optional matching?

dregad

dregad

2014-10-13 02:52

developer   ~0041559

I have no real objection with reopening, but then the description of the issue would need to be amended because with the current wording it's clearly a "won't fix". I believe it would be preferable to open a new issue to track a different requirement.

a) A method to match "foo%bar"

We can already do that today, so if this is michield's requirement then the issue can be resolved as "no change required"

b) A method to match "foo" OR "bar"

To implement this we'd need a syntax to signify the "OR" and build a parser.

michield

michield

2014-10-13 03:24

reporter   ~0041560

don't worry. I don't mind. I wrote that report in 2005, 9 years ago :-)

I guess my "improvement" is only minimal. Probably my issue is about improving the search as a whole, which presumably is dealt with in many places.

I'd have to re-check the current search to be able to properly report on it. If I do, I will create a new issue.

So, for me, fine to close this as "won't fix"