Note: This bug is displayed in read-only format because
the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Description of problem:
When filtering for 'snippet' on the Provisioning Templates page, the following error is displayed.
```
Oops, we're sorry but something went wrong wrong number of bind variables (0 for 1) in: (["(\"templates\".\"snippet\" <> ?)", false])
```
Version-Release number of selected component (if applicable):
6.8
How reproducible:
Steps to Reproduce:
1. Host >> Provisioning Temaplte.
2. In the search field, fill in exactly 'snippet' (without quotation marks)
3. Search
Actual results:
Error Oops, we're sorry but something went wrong wrong number of bind variables (0 for 1) in: (["(\"templates\".\"snippet\" <> ?)", false])
Expected results:
No error.
While I agree the error shouldn't cause 500 error, the correct syntax to filter snippets in the search box is "snippet = true" or "snippet = false", because it's the attribute of the template object.
(In reply to Marek Hulan from comment #1)
> While I agree the error shouldn't cause 500 error, the correct syntax to
> filter snippets in the search box is "snippet = true" or "snippet = false",
> because it's the attribute of the template object.
I would agree, if this would be the case for any attribute/search criteria.
I easily can use 'vendor' or 'template' and will get a result. This applies to many other criteria as well.
But for 'default_template', 'locked' the error is same as for snippet.
So this should be handled in a good manner, without showing any error (or even not 500)
Upon review of our valid but aging backlog the Satellite Team has concluded that this Bugzilla does not meet the criteria for a resolution in the near term, and are planning to close in a month. This message may be a repeat of a previous update and the bug is again being considered to be closed. If you have any concerns about this, please contact your Red Hat Account team. Thank you.
Fix submitted upstream; therefore, bugzilla will not be closed via auto-closure.
Comment 11Lukáš Hellebrandt
2023-07-18 12:49:11 UTC
Verified with Sat 6.14.0. snap 6.0.
Let "content" be any field in the template, like "name" or "description".
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)
Adam, look at 3) and 8) and let me know if you consider it a bug. I am inclined to consider it a very minor bug.
It definitely doesn't feel right, but at the same time, I don't think we have the capacity to resolve that in the foreseeable future. Considering scoped_search is a third party project, how about we report it as an issue there so it doesn't get lost and in the best case, we'll get the fix for free?
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.
For information on the advisory (Important: Satellite 6.14 security and bug fix update), and where to find the updated
files, follow the link below.
If the solution does not work for you, open a new bug report.
https://access.redhat.com/errata/RHSA-2023:6818