|Summary:||Search: provide intelligent quoting for suggestions|
|Product:||[Other] RHQ Project||Reporter:||Joseph Marques <jmarques>|
|Component:||SearchBar||Assignee:||Joseph Marques <jmarques>|
|Status:||CLOSED CURRENTRELEASE||QA Contact:||John Sanda <jsanda>|
|Fixed In Version:||2.4||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2010-08-12 16:46:32 UTC||Type:||---|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Joseph Marques 2010-07-01 15:42:15 UTC
When a user enters a search, it will provide simple suggestions. Since these suggestions may contain whitespace, all of them are blindly wrapped with double-quotes so that, upon auto-complete, the search translator will interpret multiple words as a single search token. The simple suggestions would look like: "some whitespace" "in my name" "so i get double-quoted" "by default" However, this strategy is imperfect. The issue lies in the fact that some results may actually have a double-quote in the suggestion itself. If they do, then the suggestion will look like: "suggestion with " in my name" When the user selects this suggestion and executes the search, it will be parsed and interpreted as the following search tokens <suggestion with >, <in>, <my>, <name"> Although this search will work and may result somewhat close to the correct result, it could have also suggested something that would cause the expression parsing to fail: "suggestion with"in my name" Here the parser will interpret <suggestion with> as the first token and then bomb, because there is no whitespace between it and the next token in the expression. As a result, the entire expression will be treated as invalid and no filters will be applied to the search. This can be remedied by providing a more intelligent quoting mechanism. The search suggestion generator can scan each suggestion and provide a quoting strategy that will work in a wider variety of cases: 1) do *not* wrap the suggestion in quotes, unless it contains whitespace (and thus requires wrapping to be interpreted as a single token) 2) if the expression does include whitespace then 2a) if the suggestion contains one or more double-quotes, but no single quotes, then wrap the suggestion in single-quotes 2b) conversely, if the suggestion contains one or more single-quotes but no double quotes, then wrap the suggestion in double-quotes The only case this would fail to handle eloquently is if the suggestion has whitespace, contains single-quotes, and contains double-quotes. If all three of those conditions are present, then the parser will either tokenize the expression incorrectly or the parse will fail altogether. This, however, should be a rather rare circumstance.
Comment 1 Joseph Marques 2010-07-15 16:21:44 UTC
commit 186aa9fe1f54389a86aa637577793284814c3a7d Author: Joseph Marques <firstname.lastname@example.org> Date: Thu Jul 15 12:20:14 2010 -0400 BZ-610135: provide intelligent quoting for suggestions * if a suggestion doesn't need to be quoted, don't quote it * if a suggestion has whitespace, then determine how to quote it ** if it has only single-quotes in the value, wrap it in double-quotes ** if it has only double-quotes in the value, wrap it in single-quotes ** if it has both types of quotes in the value, don't quote it *** thus, treat mixed-quoted values single search terms so the parser won't bomb
Comment 2 Corey Welton 2010-07-20 01:26:59 UTC
* if I search for something w/ no whitespaces, i.e., AlertConditionCacheManagerBean, it does not get quoted * if i search for something with whitespaces, i.e., Alert Subsystem, it gets quoted * if i search for something with single quotes, i.e., Corey's Apache Servers, it gets wrapped w/ double * if i search for something with double quotes, i.e., servers of the "real" OS, it gets wrapped with single * if I start a search for something with mixed quotes, i.e., "goofy-ass 'group name that' mak"es no sense', it does not get quoted and single terms are used * tested against resources * tested against groups. Dev can bounce this back if the appropriate test scenarios have not been thought to have been covered.
Comment 3 Corey Welton 2010-08-12 16:46:32 UTC
Mass-closure of verified bugs against JON.