Search description doesn't explain when the search type is "not equals"

RESOLVED FIXED in Bugzilla 3.4

Status

()

defect
P3
normal
RESOLVED FIXED
11 years ago
8 years ago

People

(Reporter: vitaly.fedrushkov, Assigned: mkanat)

Tracking

({ue})

3.3.1
Bugzilla 3.4
Bug Flags:
approval +
approval3.6 +
blocking3.6 +
approval3.4 +
blocking3.4.6 +

Details

(Whiteboard: [wanted-bmo], )

Attachments

(1 attachment, 1 obsolete attachment)

v2
677 bytes, patch
LpSolit
: review+
Details | Diff | Splinter Review
Reporter

Description

11 years ago
Search description for this URL:

    * Assignee: vitaly.fedrushkov@gmail.com
    * Reporter: vitaly.fedrushkov@gmail.com
    * Status: UNCONFIRMED

while boolean chart says 'Status is not equal to UNCONFIRMED'
Assignee

Comment 1

11 years ago
You can add &debug=1 if you really want a lot of information about exactly what type of chart you're using. I purposely implemented search descriptions in a way that they don't show the chart you're using. I tried doing it at first, but it was complex and wasn't very pretty.

I agree that it might be nice to show symbols for certain types of searches, like "not equal to", though. But it's not a very high priority, and probably won't be fixed for 3.4.
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P4

Comment 2

10 years ago
I have two named searches with the same set of filters, the only difference is that one has "Target Milestone is not equal to Future", the other one has "Target Milestone is equal to Future".

I see exactly the same search description for both searches that states "Target Milestone: Future", which is plain wrong. It would be better if nothing was displayed, at least it wouldn't be so misleading.
Assignee

Updated

10 years ago
Duplicate of this bug: 528960

Comment 4

10 years ago
We all agree that it's confusing as is. It's very easy to add the relationship between a field and its value.
Severity: minor → normal
Priority: P4 → P3
Assignee

Comment 5

10 years ago
  Yeah, see https://bugzilla.mozilla.org/show_bug.cgi?id=528960#c7 for my thoughts on how this would ideally work.

  (Except one slight modification is that it would be nice to use an actual "not equals" glyph if one is standardly available in browser fonts, instead of "!=".)

Updated

10 years ago
Duplicate of this bug: 541383
This needs to be fixed for 3.6, even if it means just taking a simple patch like what's in bug 528960.
Flags: blocking3.6?
Keywords: ue
Whiteboard: [wanted-bmo]

Comment 8

9 years ago
Perhaps I'm being a bit dumb about this but is the BIG problem that the query is for "NOT equal" and the result appears as if it is "equal to"? I agree that's a bad thing. 

I kinda wish we could use a ! to say not but i think that's a bit computer sciencey, maybe we just do NOT(Status: UNCONFIRMED) ?

Is there a good standard way to show not equal to? I did like how the colon was kinda ambiguous between the equal to, contains etc.
Assignee

Comment 9

9 years ago
Turns out I'd always intended the code to behave that way and it simply wasn't working right for notequals.
Flags: blocking3.6?
Flags: blocking3.6+
Flags: blocking3.4.6+
Summary: Search description is misleading about boolean charts → Search description doesn't explain when the search type is "not equals"
Target Milestone: --- → Bugzilla 3.4
Assignee

Comment 10

9 years ago
Posted patch v1 (obsolete) — Splinter Review
One-character patch.
Assignee: query-and-buglist → mkanat
Status: NEW → ASSIGNED
Attachment #429359 - Flags: review?(LpSolit)
(In reply to comment #9)
> Turns out I'd always intended the code to behave that way and it simply wasn't
> working right for notequals.

Is notequals what is actually causing all of the problems mentioned in bug 528960, comment #0? Seems like those issues are tied to "does not contain the string" rather than "not equal to"...
Assignee

Comment 12

9 years ago
Posted patch v2Splinter Review
This version includes all the negatives.
Attachment #429359 - Attachment is obsolete: true
Attachment #429371 - Flags: review?(LpSolit)
Attachment #429359 - Flags: review?(LpSolit)
Reporter

Comment 13

9 years ago
(In reply to comment #8)
> Is there a good standard way to show not equal to? 

Why not 

http://www.fileformat.info/info/unicode/char/2260/index.htm

?
Assignee

Comment 14

9 years ago
  That's what I was thinking as well, Vitaly. It would have to be a bit bigger than usual so people could clearly see the slash through it.

  However, changing the search descriptions to glyphs would be a separate bug from this one.
Comment on attachment 429371 [details] [diff] [review]
v2

r=LpSolit
Attachment #429371 - Flags: review?(LpSolit) → review+

Updated

9 years ago
Flags: approval3.6+
Flags: approval3.4+
Flags: approval+
Assignee

Comment 16

9 years ago
Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/trunk/                       
modified template/en/default/list/list.html.tmpl
Committed revision 7035. 

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/3.6/                         
modified template/en/default/list/list.html.tmpl
Committed revision 7006.

Committing to: bzr+ssh://bzr.mozilla.org/bugzilla/3.4/                         
modified template/en/default/list/list.html.tmpl
Committed revision 6733.
Status: ASSIGNED → RESOLVED
Last Resolved: 9 years ago
Resolution: --- → FIXED

Comment 17

8 years ago
4rdf dddddd fawd fawd efew3 3erfdcv Erfc Afc Ef d @WEDRf v f WE#QRfexs   ewrt sd Sds sdasc ASdAc zc acascf zcc ccc Zasfaf sdAcsawd vzv sfc SDvvrw vv gv s  g vuhgr  urthg ifgoiuergkijkfjguujriao;; ;poplhyw54ui7
You need to log in before you can comment on or make changes to this bug.