528960 - New search summary of bugzilla query is wrong sometimes and needs UI cleanup

Status: RESOLVED DUPLICATE of bug 474738

(Bugzilla :: Query/Bug List, defect)

Description

[Samuel Sidler (old account; do not CC)]

Given a query: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20blocking1.9.1:.6%2B%20-status1.9.1:.6-fixed%20-flag:approval1.9.1.6%2B%20-flag:approval1.9.1.6%3F&order=map_assigned_to.login_name,bugs.bug_id

This should be equal...

  * all bugs regardless of status
  * blocking1.9.1 is equal to ".6+"
  * status1.9.1 does not contain .6-fixed
  * bug does not have flag approval1.9.1.6+
  * bug does not have flag approval1.9.1.6?

But the top of the bug list page says:
    * blocking1.9.1:  .6+
    * status1.9.1: .6-fixed
    * Flag: approval1.9.1.6+
    * Flag: approval1.9.1.6?

Apparently it doesn't know negatives?

This isn't really a regression since this feature didn't exist before the upgrade, but it's still bad. An appropriate resolution for this bug could also be turning off the feature altogether.

Comment 1

[Frédéric Buclin]

It indeed doesn't know negatives. We should try to make it a bit more clever and know about them, as well as grouping data when possible (Jesse mentioned that on IRC already).

Note that this summary is in <ul class="search_description">, so you can easily hide it if you want to.

Comment 3

[Samuel Sidler (old account; do not CC)]

For BMO, I think the feature should be disabled. It's confusing to people who run a query and Bugzilla effectively tells them they made the wrong query.

Comment 4

[Frédéric Buclin]

Attachment: partial fix, v1

All it does is to add the relationship between the field and its value. Some more UI cleanup to come later.

Comment 5

[Thomas D. (:thomas8)]

If bug 528962 is a duplicate, then UI cleanup is part of this bug (adjusting summary accordingly): For a quicksearch with multiple searchwords, the summary goes wild by adding the full sequence of field headers all over again for every searchword, which is impossible to parse and wasting a lot of space.

Comment 6

[Frédéric Buclin]

(In reply to comment #5)

Yeah, yeah, don't worry. :)

Comment 7

[Max Kanat-Alexander]

Comment on attachment 412627 [details] [diff] [review]
partial fix, v1

Actually, I thought I'd added this for certain types already--I'm surprised I hadn't. Maybe there was a mixup with the patches that I posted.

What I'd really like to see is:

* For all the "equals" types, don't show anything.

* For certain common unusual types (regex, greaterthan, notequals), show a symbol (~, >, !=)

* For the other unusual types, show the whole search type description.

Also, I'm pretty certain this bug is a dupe.

Comment 9

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to comment #3)
> For BMO, I think the feature should be disabled. It's confusing to people who
> run a query and Bugzilla effectively tells them they made the wrong query.

Is this possible ? I agree with Sam the search summary is very misleading.

Comment 10

[Max Kanat-Alexander]

(In reply to comment #9)
> (In reply to comment #3)
> > For BMO, I think the feature should be disabled. It's confusing to people who
> > run a query and Bugzilla effectively tells them they made the wrong query.
> 
> Is this possible ? I agree with Sam the search summary is very misleading.

  It's currently possible with your userContent.css, at the least, since the summary is all enclosed in an element that is styleable.

Comment 11

[Thomas D. (:thomas8)]

Max, can you tell us the path to userContent.css? Is it a) on the server where bugzilla is installed, or b) on the end user's personal machine? If a), how does it help to solve the problem?

Comment 12

[Frédéric Buclin]

(In reply to comment #11)
> Max, can you tell us the path to userContent.css?

This is a file in your Firefox profile directory, in chrome/. You can add CSS rules to hide the part of the UI you don't want.