Closed Bug 474738 Opened 12 years ago Closed 10 years ago
Search description doesn't explain when the search type is "not equals"
Search description for this URL: * Assignee: firstname.lastname@example.org * Reporter: email@example.com * Status: UNCONFIRMED while boolean chart says 'Status is not equal to UNCONFIRMED'
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
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.
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
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 "!=".)
This needs to be fixed for 3.6, even if it means just taking a simple patch like what's in bug 528960.
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.
Turns out I'd always intended the code to behave that way and it simply wasn't working right for notequals.
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: 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"...
This version includes all the negatives.
(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 ?
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+
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
Closed: 10 years ago
Resolution: --- → FIXED
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.