Bug 1497185 - Granular search of name with ^ symbol is not working.
Summary: Granular search of name with ^ symbol is not working.
Keywords:
Status: CLOSED NEXTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: Docs Server Administration Guide
Version: 6.2.12
Hardware: x86_64
OS: Linux
medium
high vote
Target Milestone: Unspecified
Assignee: csherrar
QA Contact: Russell Dickenson
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-09-29 12:20 UTC by maneesh verma
Modified: 2020-12-14 10:18 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-11-24 04:29:36 UTC
Target Upstream Version:


Attachments (Terms of Use)

Description maneesh verma 2017-09-29 12:20:25 UTC
Description of problem:

Not able to use Granular search in Satellite as specified in the document.

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/server_administration_guide/sect-red_hat_satellite-server_administration_guide-users_and_roles-granular_permission_filtering

How reproducible:

Everytime you go for a search of Host, filter, config_groups

Steps to Reproduce:
1.Create 3 config groups with 1 starting with upper case letter.(abc1, Abc2, abc3)
2.Now in Configure>config groups> Search with filter "name ^"  it will display all the config groups.
3.If you specify name ^ a letter it will still display all the 3 config groups.

Actual results:

using name ^ as search filter shows all the hosts or config groups.

Expected results:

When using name ^ letter name it should show only data starting with upper case letter.

Comment 2 Marek Hulan 2017-10-03 18:12:12 UTC
Thanks for the report. Why do you think that only upcase names should be suggested after ^? Please note that ^ is "in" operator. IIRC it's documented in product documentation. If there's some docs suggestin it's related to upcase, please provide a link, so w can fix it. Otherwise please close as notabug
Also WebUI is not the right component, Search would be appropriate.

Comment 3 John Reid 2017-10-03 18:20:57 UTC
I think they didn't word it quite correctly. Given config groups abc1, Abc2, abc3, if you search "name ^ a", there are no results, where expected results are abc1, abc3 (because product documentation says this is a case-sensitive search)

Comment 4 maneesh verma 2017-10-04 08:47:22 UTC
Hello

In the given documentation below-

https://access.redhat.com/documentation/en-us/red_hat_satellite/6.2/html/server_administration_guide/sect-red_hat_satellite-server_administration_guide-users_and_roles-granular_permission_filtering
 In table 4.2 it is mentioned that if I use "^" with a letter it will filter only the names starting with upper case.

But that is not actually how search function is working.

Thanks
Maneesh

Comment 5 Marek Hulan 2017-10-10 09:41:02 UTC
Then this is a documentation bug, it's not clear enough. The ^ is IN operator, therefore it would find only record that are in a given set. In an example that John provided, "name ^ a" does not return anything because there's no config group with name "a". Note that it requires full name, so e.g. name ^ (abc1,Abc2,a) would return 2 config groups, abc1 and Abc2, config group with name "a" does not exist.

What you could use is "name ~ a" which searches for all records that contains letter a in name, but it's case insensitive.

Maneesh I didn't see anything sayng "upper case" or "starting" in the link you provided. What I see is "In. A case-sensitive search for text fields containing a certain string."

I think the work "containing" is misleading it should be probably replaced with "equal to". An example would help too. Moving to related documentation component.

Comment 6 maneesh verma 2017-10-10 10:00:11 UTC
Hello

Customer finding the details in table no 4.2-

^	In. A case-sensitive search for text fields containing a certain string.

So above it shows that it is case sensitive search, same customer is using.

Comment 7 Marek Hulan 2017-10-10 13:47:54 UTC
It is case sensitive, but it does not search by starting letter. It returns records that are one of the given values. Therefore "name ^ a" would return the record if name is "a", not records that contain a. It wouldn't even return object with name "A" since it is case sensitive.

Comment 8 maneesh verma 2017-10-10 13:52:41 UTC
Not getting the last comment.

Base query is if I have 4 config-groups and 1 has a upper case how do I filter them to show only upper case config-group.

Comment 9 John Reid 2017-10-10 14:05:00 UTC
There are 2 parts to this: the caret in bash, regex and other environments use this to mean "begins with" this is what the gui search function is trying to do (not in the actual searching, just while entering search terms). In the web interface, when you start typing in a search box, it tries to finish it for you. If you type "name ^ a", the search suggests "abc1" and "a" as possible completions for your search. But the actual results are as you explained: only complete, case-sensitive matches are returned. 

The second part, the documentation says "containing" when it should say something like "equals" if it's supposed to return like you've said. 

But as a related note, if caret is meant to be a case-sensitive "equal to", what's the difference between '=' and '^' in the search function?

Comment 10 Marek Hulan 2017-10-10 14:30:40 UTC
John, you're right. The difference between = and ^ is that if you want to specify more values, ^ is less repetitive and more efficient when it triggers the SQL.

compare these two:
> name = a or name = b
> name ^ (a,b)

the first will trigger SQL query WHERE name = "a" or name = "b", the second will do WHERE name IN ("a","b").

For the auto suggestion in search box, it suggest complete values, which is consistent with with when you start "name = a", it would also suggest abc1. We're not forcing auto suggested values so if you don't choose it, you end up with what you typed. I don't think that's a bug.

Comment 11 John Reid 2017-10-10 15:26:00 UTC
You're exactly right on that search suggested values. Somehow, I only just realized after you said it that it's trying to finish your search query for you, not show expected results. Definitely a strange conclusion that I somehow came to originally, and definitely not a bug. 

So, having the documentation changed from "containing" to "equal to" I think is the only thing left then. And actually, I think if they could work in your last explanation, that would be pretty helpful for folks like me that aren't aware of the difference between = or ^.

Comment 14 Marek Hulan 2017-10-11 10:41:01 UTC
Thanks for confirmation John. This BZ will track fixing of the documentation.

Comment 15 Andrew Dahms 2017-11-09 01:35:56 UTC
Assigning to Clifton for review.

Clifton - see the last few above comments for some details on what is required in this bug.

Comment 25 Andrew Dahms 2017-11-24 04:29:36 UTC
These changes shall be published with the next release of the Red Hat Satellite 6.3 documentation.


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