-
Bug
-
Resolution: Fixed
-
Critical
-
4.1.0
-
None
-
None
-
4.1 M6
The - character is not considered. and I cannot find any contents when I type this character in the select-content widget.
Then if I try to search contents with a - in their titles, I'm unable to find it.
[CMS-8759] [Widget] The character - is breaking the search in the select-content widget
Cédric Damioli
added a comment - I prefer we do NOT split/transform/tokenize the input request in any way : it's Solr job, not ours.
Cédric Damioli
added a comment - I prefer we do NOT split/transform/tokenize the input request in any way : it's Solr job, not ours.
Simon Prieul (Inactive)
added a comment - The issue was in SelectContent:525, before sending request to server, we do:
if (query) { query = '*' + query + '*'; }
so as to benefit from wildcard characters with the SEARCH query (on title_txt_fr) and match "Article" if the widget contains "Art" for example (to return all documents beginning with the widget content).
But with this strategy, the dash character broke the search and a search with "foo-bar" generates the following query: title_txt_fr:(*foo-bar*) and the document "foo-bar" does not match.
So I propose to generate the following query: title_txt_fr:(*foo* *bar*), which can be done with the following code:
if (query) { query = query.split(/\W/) // split in order to keep words only such as "foo-bar baz*qux" becomes ["foo", "bar", "baz", "qux"]. Delimiters are purely ignored .filter(function(w) {return w.length > 0}) .map(function(w) {return '*' + w + '*';}) .join(' '); // join to get the result string, such as "*foo* *bar* *baz* *qux*" }
Consequently, delimiters are purely ignored and cannot be searched ('-', '*', '+', '.', etc.), but it is really a problem ?
What's your opinion ?
Simon Prieul (Inactive)
added a comment - The issue was in SelectContent:525, before sending request to server, we do:
if (query)
{
query = '*' + query + '*' ;
}
so as to benefit from wildcard characters with the SEARCH query (on title_txt_fr ) and match "Article" if the widget contains "Art" for example (to return all documents beginning with the widget content).
But with this strategy, the dash character broke the search and a search with "foo-bar" generates the following query: title_txt_fr:(*foo-bar*) and the document "foo-bar" does not match.
So I propose to generate the following query: title_txt_fr:(*foo* *bar*) , which can be done with the following code:
if (query)
{
query = query.split(/\W/) // split in order to keep words only such as "foo-bar baz*qux" becomes [ "foo" , "bar" , "baz" , "qux" ]. Delimiters are purely ignored
.filter( function (w) { return w.length > 0})
.map( function (w) { return '*' + w + '*' ;})
.join( ' ' ); // join to get the result string, such as "*foo* *bar* *baz* *qux*"
}
Consequently, delimiters are purely ignored and cannot be searched ('-', '*', '+', '.', etc.), but it is really a problem ?
What's your opinion ? 
Be careful, the ReferenceTableSearchUIModel class should be take into account. It is used to generate search model for reference table dynamically.
If the "title" with like operator have to be added, it should be added here too. SelectReferenceTableContent use this dynamic search model.
Be aware also of the all parameters which to not use the default model "select-content". For exemple, in ODF, to select ODF person, this is the "select-person.xml" search model which is use. Do necessary modifications.