Bug 1497185

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.

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)

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

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.

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.

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.

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.

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?

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.

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 ^.

Thanks for confirmation John. This BZ will track fixing of the documentation.

Assigning to Clifton for review.

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

These changes shall be published with the next release of the Red Hat Satellite 6.3 documentation.