518459 - Remove certain QuickSearch features that are no longer needed and may be confusing

Status: RESOLVED FIXED

(Bugzilla :: Query/Bug List, enhancement)

Description

[Max Kanat-Alexander]

One of the big projects for Bugzilla 3.6 is bug 490549, which combines quicksearch and full-text search, which means that QuickSearch will become one of the main methods of search for average Bugzilla users.

There are various shortcuts that were useful and sensible for Mozilla (which was the only real quicksearch user when quicksearch was originally written) that aren't as sensible for the average user, particularly after we have bug 518024, which should switch users away from using shortcuts and special words and over to using the field names explicitly (which is easy enough to do and generally much simpler than typing in special words).

Also, the current implementation of some special things is such that they involve words that people might actually want to do a full-text search for (like "windows" or "pc") but they would be prevented from searching for by the magical quicksearch syntax.

Comment 1

[Frédéric Buclin]

Could you be more explicit on what you would like to see going away?

Comment 2

[Max Kanat-Alexander]

Attachment: v1

Okay, this removes the following features for the following reasons:

* Magical searching of platform/os by a list in a constant
  First off, platform and OS are customizable nowadays. Also, they represent
  words that people might actually want to search for in quicksearch.
  If people actually want to explicitly search these fields, they can do
  os:value or plat:value easily enough now.

* + as a prefix for statuses/resolutions, and + as a prefix for searching
  just short_desc.
  + is actually used in fulltext searching to activate the boolean search
  method, and means "the search must contain this value". So we need to pass
  + through without interpreting it.
  For status/reso, you can still just do "FIX,DUP" at the beginning of the
  search, and for summary, you can just do "summ:value".

* Magical searching of priority by typing the name of the priority in as
  a bare word.
  Priorities are customizable, and this could get confusing, particularly
  now that we're going to give them normal English names.
  I kept the P1-P3 syntax, though, so people can still use that--I can't
  imagine somebody wanting to fulltext search for a literal "P1".

* Magical searching of severities by a bare word matching the first three
  characters of that severity.
  This is a bit too magical for most people, and also, those three characters
  (particularly with customizable severities) could be something somebody
  validly wants to instead do a fulltext search for.


  The one thing I'm not sure about is -. That means "the search must not contain this value" in the fulltext search, but it also already means that same thing in QuickSearch. So I'm going to let QuickSearch interpret it instead of the fulltext engine, for now.

Comment 3

[Frédéric Buclin]

Comment on attachment 402464 [details] [diff] [review]
v1

> sub _special_field_syntax {

>-    my $legal_priorities = get_legal_field_values('priority');

$legal_priorities is used at several other places:

t/001compile.t ....... 4/171 # Global symbol "$legal_priorities" requires explicit package name at Bugzilla/Search/Quicksearch.pm lines 445, 446, 447, 449.

So either the remaining code using it must go away too, or this variable must stay.


Also, while you are removing some magical tricks, why not also removing PRODUCT_EXCEPTIONS and COMPONENT_EXCEPTIONS? These constants are clearly Mozilla-centric.

Comment 4

[Daniel Veditz [:dveditz]]

(In reply to comment #3)
> Also, while you are removing some magical tricks, why not also removing
> PRODUCT_EXCEPTIONS and COMPONENT_EXCEPTIONS? These constants are clearly
> Mozilla-centric.

And yet they solve a real and seriously inconvenient problem.

I admit hardcoding the list is icky and Mozilla-centric, but the solution would be to make it configurable rather than remove it. Other projects would have similar conflicts between common search words matching everything in a common product name. Another solution that would be fine by me (but would probably upset the people who use it a lot) is to make quicksearch not search products and component names unless you specifically say to (e.g. ":mail").

Comment 5

[Max Kanat-Alexander]

Yeah, perhaps we should think about removing EXCEPTIONS (or making them configurable) in a separate bug.

Comment 6

[Frédéric Buclin]

(In reply to comment #4)
> Another solution that would be fine by me (but would probably
> upset the people who use it a lot) is to make quicksearch not search products
> and component names unless you specifically say to (e.g. ":mail").

This would make sense to me. And this would let us remove these exceptions from QS.

Comment 7

[Max Kanat-Alexander]

Well, that's not a behavior I want to change at this point, as it's not clearly obvious that we should be removing it. That's something we can talk about for 3.8 in another bug.

Comment 8

[Max Kanat-Alexander]

Attachment: v2

Okay, this fixes the compile error.

Comment 9

[Frédéric Buclin]

Comment on attachment 418113 [details] [diff] [review]
v2

Looks good now. r=LpSolit

Comment 10

[Max Kanat-Alexander]

Checking in Bugzilla/Search/Quicksearch.pm;
/cvsroot/mozilla/webtools/bugzilla/Bugzilla/Search/Quicksearch.pm,v  <--  Quicksearch.pm
new revision: 1.28; previous revision: 1.27
done

Comment 11

[Max Kanat-Alexander]

Added to the release notes in bug 547466.