Bug 2224010

Summary: Inconsistency in quoted field name interpretation
Product: Red Hat Satellite Reporter: Lukáš Hellebrandt <lhellebr>
Component: SearchAssignee: satellite6-bugs <satellite6-bugs>
Status: NEW --- QA Contact: Satellite QE Team <sat-qe-bz-list>
Severity: low Docs Contact:
Priority: unspecified    
Version: 6.14.0CC: rlavi
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Lukáš Hellebrandt 2023-07-19 14:45:10 UTC
Description of problem:
Sometimes, quoted string (consisting of some field's name) is interpreted as a field's bool value. Sometimes, it's not. For example, "snippet" translates to "all entries where snipped field is set to true", BUT "!snippet" translates to "all entries where some field contains string '!snippet'". This is inconsistent.

Version-Release number of selected component (if applicable):
Sat 6.14, behavior allowed by fixing bug 1949960.

How reproducible:
Deterministic

Steps to Reproduce:
Searching in Hosts -> Provisioning templates:
0) snippet => all snippets
1) !snippet => all non-snippets
2) "snippet" => somewhat counter-intuitively all snippets but I could let this pass
3) "!snippet" => nothing, only would return whatever contains "!snippet" in its content - this is inconsistent with 2) where "snippet" is interpreted as "value of 'snippet' field is true"
4) name ~ snippet => all templates that contain "snippet" in their content
5) default => snippets with "default" in their content
6) default_template => templates marked as default
7) "default" => same as 5)
8) "default_template" => same as 6)
9) default_template = true => same as 7)
10) "!default_template" => nothing, again inconsistently with 8), the same issue as with 3)

Actual results:
2) and 3), 10) and 8) are inconsistent.

Expected results:
Both should be either translated to "field's bool value is true/false " or "string contained in fields" (IMO preferrably, since quotes are used).

Additional info:
According to aruzicka, this is an issue in scoped_search. The bug manifests in our product, though, and we even have Search component so I'm reporting it here.