Bug 2058660
Summary: | The search functionality and logics for the "Administer --> Settings" page are completely broken in Satellite 6.11 | ||
---|---|---|---|
Product: | Red Hat Satellite | Reporter: | Sayan Das <saydas> |
Component: | Settings | Assignee: | satellite6-bugs <satellite6-bugs> |
Status: | CLOSED MIGRATED | QA Contact: | Satellite QE Team <sat-qe-bz-list> |
Severity: | medium | Docs Contact: | |
Priority: | medium | ||
Version: | 6.11.0 | CC: | afeferku, ahumbe, apatel, dalley, kgaikwad, lstejska, mhulan, ogajduse, rlavi |
Target Milestone: | Unspecified | Keywords: | MigratedToJIRA, Regression, Triaged |
Target Release: | Unused | ||
Hardware: | All | ||
OS: | All | ||
Whiteboard: | |||
Fixed In Version: | Doc Type: | If docs needed, set a value | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2024-06-06 11:33:33 UTC | 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
Sayan Das
2022-02-25 14:41:16 UTC
Hi, This issue is coming from the refactoring of the code responsible for handling settings, there were some major changes in how we store and access settings data. Due to these changes we implement a scope search method by our own [0] and right now this implementation doesn't support ":or" and ":and" operators. The problem is that with current implementation it would be really difficult to implement ":and" and ":or" operators, and I'm quite sure it is impossible to make it in the 6.11 release. But that doesn't mean we can't do anything, I’ve been thinking about possible solution how to make it more user-friendly, here is my proposal what we can do: 1) Implement "name ~ value" for :name (and :full_name) 2) Ban “:and” and ":or" operators - If users try to search with these operators, Satellite will raise exception with forbidden search query. 3) Update API documentation and describe allowed search method 4) Create BZ for the issue with ":and" ":or" operators I know that in optimal case we should allow user to scope multiple queries, but sadly that would require a lot of refactoring in our code base for which we don’t have time now. Please let me know what you think, feel free to ping me on the google chat, we can meet and discuss the possible solutions that would fit best for customers. Created redmine issue https://projects.theforeman.org/issues/34864 from this bug Hello Leos, Thanks for reaching out and also sharing your opinion about the concern reported. I have no issues even if this does not gets into 6.11 GA. It's not something major that will break any Administrative functionalities in Satellite but the glitch is there and it is a regression. It's unrelated to this BZ but if you see https://bugzilla.redhat.com/show_bug.cgi?id=1872041#c3 , you can come to know how some users will report this kind of glitches even if they have a work around with them. My point of view: 1. I would expect the search functionality in all pages of satellite should remain the same i.e. from the perspective of the way we search things and the operators we use. 2. Or / Like (~) / Equals (=) are three very important operators\search factors and should be present as well as working on this Settings page along with the free form search(which already works). We don't know how customers are used to searching and hence we cannot neglect the possibility of someone will definitely use one or more of the methods mentioned above. Keeping these two points under consideration, please see what can be done to fix this glitch. And as I had mentioned before, It need not explicitly land on 6.11.0 but it can go in 6.11.z If that helps anyway. I created new BZ (https://bugzilla.redhat.com/show_bug.cgi?id=2082076) for 6.11, where I fix following cases: * Allow '~' operator for name * Fix issue with double quote in search * Raise exception for unsupported operators :and / :or Issue with ":and" / ":or" operators will be fixed later in this BZ. I propose then to remove this BZ from 6.11 scope, the code change required for fix of ":and/:or" is not doable in 6.11 deadline. *** Bug 2090799 has been marked as a duplicate of this bug. *** 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. Based upon feedback during auto-closure, leaving this bugzilla open a while longer for additional investigation; however, it may be closed in a future iteration. This BZ has been automatically migrated to the issues.redhat.com Red Hat Issue Tracker. All future work related to this report will be managed there. Due to differences in account names between systems, some fields were not replicated. Be sure to add yourself to Jira issue's "Watchers" field to continue receiving updates and add others to the "Need Info From" field to continue requesting information. To find the migrated issue, look in the "Links" section for a direct link to the new issue location. The issue key will have an icon of 2 footprints next to it, and begin with "SAT-" followed by an integer. You can also find this issue by visiting https://issues.redhat.com/issues/?jql= and searching the "Bugzilla Bug" field for this BZ's number, e.g. a search like: "Bugzilla Bug" = 1234567 In the event you have trouble locating or viewing this issue, you can file an issue by sending mail to rh-issues. You can also visit https://access.redhat.com/articles/7032570 for general account information. |