Given a query: https://bugzilla.mozilla.org/buglist.cgi?quicksearch=ALL%20blocking1.9.1:.6%2B%20-status1.9.1:.6-fixed%20-flag:approval126.96.36.199%2B%20-flag:approval188.8.131.52%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 approval184.108.40.206+ * bug does not have flag approval220.127.116.11? But the top of the bug list page says: * blocking1.9.1: .6+ * status1.9.1: .6-fixed * Flag: approval18.104.22.168+ * Flag: approval22.214.171.124? 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.
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.
Assignee: nobody → query-and-buglist
Component: Bugzilla: Other b.m.o Issues → Query/Bug List
Product: mozilla.org → Bugzilla
QA Contact: other-bmo-issues → default-qa
Version: other → 3.4.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.
All it does is to add the relationship between the field and its value. Some more UI cleanup to come later.
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.
Summary: New summary of query is wrong sometimes → New search summary of bugzilla query is wrong sometimes and needs UI cleanup
(In reply to comment #5) Yeah, yeah, don't worry. :)
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.
Attachment #412627 - Flags: review-
Status: NEW → RESOLVED
Last Resolved: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 474738
(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.
(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.
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?
(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.
You need to log in before you can comment on or make changes to this bug.