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)
Hello Team, The customer is looking for updates on this Bugzilla? Do we have an ETA for this?
No update on better handling the 500 errors on invalid syntax. The searching works.
I also renamed the BZ to better describe the issue and moved it to the component that fits better.
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.
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?