Bug 832978 - Wild card search query on strings including latin-1 characters does not give expected results
Wild card search query on strings including latin-1 characters does not give ...
Status: CLOSED WORKSFORME
Product: Red Hat Satellite 6
Classification: Red Hat
Component: WebUI (Show other bugs)
6.0.1
Unspecified Unspecified
unspecified Severity medium (vote)
: Unspecified
: --
Assigned To: Justin Sherrill
Katello QA List
: TestBlocker, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2012-06-18 06:06 EDT by Sachin Ghai
Modified: 2015-04-20 07:05 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2014-06-03 09:37:48 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Sachin Ghai 2012-06-18 06:06:19 EDT
Description of problem:
Wildcard character search is not working with latin-1/spanish characters.
for e.g.
when we create org with name say: test and best; we can get both name
by search string like: name:?est

However, if I create org with spanish: niños and siños. then search
returns nothing with name:?iños

There are few other possible ways I tried:

si os ==> doesn't return anything in result ( space is between si and os)
si?os ==> returns siños
?iños ==> doesn't return anything in result
?i?os ==> returns both niños and siños
 
If I replace 'ñ' with wild card character '?', search behaves
correctly

Version-Release number of selected component (if applicable):
katello-cli-common-0.1.111-1.el6_2.noarch
katello-0.1.317-1.el6_2.noarch
katello-cli-0.1.111-1.el6_2.noarch
pulp-1.0.4-1.el6.noarch
elasticsearch-0.18.4-11.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. Create org with name niños and siños
2. now perform search query like: name:?iños
3.
  
Actual results:
Serach query (name:?iños) doesn't return anything in result, however if I replace 'ñ' with wild card character '?', search behaves
correctly

Expected results:
Serach query (name:?iños) should return  niños and siños in result as per above example.

Or Wild card characters should work on latin-1 strings as with normal US language strings.


Additional info:
Comment 2 Mike McCune 2013-08-16 14:06:46 EDT
getting rid of 6.0.0 version since that doesn't exist
Comment 5 Justin Sherrill 2014-06-02 18:07:20 EDT
I am not able to reproduce this currently.  Organizations have been moved to foreman and thus use scoped search, however with 'host collections':

Created two: niños and siños.

Performed the following searches:


name:?iños  ==> Returned both

si os ==> doesn't return anything in result 

This shouldn't return anything.  You can try si*  or *os  to return what you would expect.

si?os ==> returns siños as expected
?iños ==> returns both 
?i?os ==> returns both


So this all seems to be working as expected.
Comment 6 Sachin Ghai 2014-06-03 02:56:31 EDT
@Justin: The bug was originally filed against org search. And looks like now I can not use wildcard characters while performing org search. Is it because of scoped search ? If that's the case then I'll close this bz.

Also, with 'host collections' the search using above latin-1 chars works perfectly.
Comment 7 Bryan Kearney 2014-06-03 08:50:05 EDT
spoke with og.. not a blocker.
Comment 9 Justin Sherrill 2014-06-03 09:23:44 EDT
@Sachin,  yes, organizations (and all entities within foreman) use scoped search.

I think you can accomplish similar to what you want with:

name ~ ACME

That would search for anything with ACME.

Feel free to close !
Comment 10 Sachin Ghai 2014-06-03 09:37:48 EDT
thanks Justin, I created two orgs(niños and siños) and search for ~iños and search returns both niños and siños.

So with new UI(in sat6 beta snap7 compose2), the search query gives expected results as per bz description. So closing this bz.
Comment 11 Sachin Ghai 2015-04-20 07:05:10 EDT
Clearing need_info flag

Note You need to log in before you can comment on or make changes to this bug.