Closed
Bug 179302
Opened 22 years ago
Closed 22 years ago
'anyexact' isn't an option for boolean charts
Categories
(Bugzilla :: Query/Bug List, enhancement)
Tracking
()
RESOLVED
FIXED
Bugzilla 2.18
People
(Reporter: bbaetz, Assigned: bbaetz)
Details
Attachments
(1 file)
940 bytes,
patch
|
bugreport
:
review+
|
Details | Diff | Splinter Review |
The 'anyexact' query type doesn't appear to be accessible from boolean charts. It works if you hack the html, and I can't see why we'd want to disallow it. Thoughts?
Assignee | ||
Comment 1•22 years ago
|
||
This is trivial if we decide to do this
Summary: 'anyexact' isn;t an option for boolean charts → 'anyexact' isn't an option for boolean charts
Target Milestone: --- → Bugzilla 2.18
Comment 2•22 years ago
|
||
No reason why we shouldn't do it, is there? However, history shows us it wasn't in that list even before templatisation, so there might be a good reason: http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/webtools/bugzilla/query.cgi&rev=1.92&root=/cvsroot Line 876. Gerv
Assignee | ||
Comment 3•22 years ago
|
||
right; its not present in my 2.14 tree. I'm guessing it was added later to buglist, and never added to the query stuff, but that is just a guess Dave/myk: do you know why? Its usable by tweaking the html, so it can't be for any particuarlyl drastic reason. Suggestions for a description to use?
Assignee | ||
Comment 5•22 years ago
|
||
This is really trivial; its just a ui change. The backend is well stested, since thats what most of the non-boolean chart stuff uses internally
Assignee | ||
Updated•22 years ago
|
Attachment #105905 -
Flags: review?(bugreport)
Comment 6•22 years ago
|
||
Comment on attachment 105905 [details] [diff] [review] trivial patch r=joel anyexact is not very forgiving.... "abc,grrgrr" matched the bug with "abc" and the one with "grrgrr". "abc grrgrr" did not nor did "abc, grrgrr"
Attachment #105905 -
Flags: review?(bugreport) → review+
Assignee | ||
Comment 7•22 years ago
|
||
We don't want spaces to separate, but I can see an argument for trimming. The only problem with that is that anyexact is ued internally quite a bit, so if we changed that then we may end up trimming on other (non-boolean) queries where we didn't in the past. I don't know if thast an issue. I think I'll leave it as is until/unless someone files a bug, then we can discuss. FIXED
Status: NEW → RESOLVED
Closed: 22 years ago
Resolution: --- → FIXED
Comment 8•22 years ago
|
||
The fix would be pretty trivial; change the "[, ]" split in the search code to /,?\s+/. Gerv
Assignee | ||
Comment 9•22 years ago
|
||
gerv: We definately don't want to split on spaces. Partly because I should be able to search on 'the cat,the mat', but also because we use anyexact internally, and things would then break. For example, searching on product=foo or product=bar from the <select> becomes 'anyexact' 'foo,bar', which is then resplit later The same argument applies to trimming the result of the split. /me wonders what happens if you search on a product with a , in teh name... I suspect that our result code needs to be able to deal with arrayrefs, not just values, but thats a separate (and much much larger) bug
Comment 10•22 years ago
|
||
> /me wonders what happens if you search on a product with a , in teh name...
Bad things. There's a bug open currently on bad things happening when you try
and search for a comma.
Gerv
Updated•12 years ago
|
QA Contact: matty_is_a_geek → default-qa
You need to log in
before you can comment on or make changes to this bug.
Description
•