Bug 596964
Summary: | [RFE] system filtering, same search types should default to or instead of and | ||
---|---|---|---|
Product: | [Retired] Beaker | Reporter: | Jeff Burke <jburke> |
Component: | web UI | Assignee: | beaker-dev-list |
Status: | CLOSED WONTFIX | QA Contact: | |
Severity: | low | Docs Contact: | |
Priority: | medium | ||
Version: | 0.5 | CC: | bpeck, mastyk, mcsontos, tools-bugs, xuzhang |
Target Milestone: | --- | Keywords: | FutureFeature, Triaged |
Target Release: | --- | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | http://tinyurl.com/2uwajut | ||
Whiteboard: | UX | ||
Fixed In Version: | Doc Type: | Enhancement | |
Doc Text: | Story Points: | --- | |
Clone Of: | Environment: | ||
Last Closed: | 2020-06-02 12:01:20 UTC | Type: | --- |
Regression: | --- | Mount Type: | --- |
Documentation: | --- | CRM: | |
Verified Versions: | Category: | --- | |
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
Cloudforms Team: | --- | Target Upstream Version: | |
Embargoed: |
Description
Jeff Burke
2010-05-27 20:16:29 UTC
I see what you mean. Perhaps though we should have another column which specifies the relationship. I can think of instances where we might want the relationship to be and (i.e System/Arch). Hi, I would like to have this, too. Searches are limited to queries in a form: 'machine contains this hw AND this CPU'. But what if I'm looking for 2 different PCI ID's? This would be really handy. Another scenario is that you want to search for CPU codename but it can be hidden in different key/value pairs: Nehalem: System/Model, CPU_CODENAME https://beaker.engineering.redhat.com/?systemsearch-0.table=System%2FModel&systemsearch-0.keyvalue=CPU_CODENAME&systemsearch-0.operation=contains&systemsearch-0.value=Nehalem&Search=Search&systemsearch_column_System%2FArch=System%2FArch&systemsearch_column_System%2FModel=System%2FModel&systemsearch_column_System%2FName=System%2FName&systemsearch_column_System%2FStatus=System%2FStatus&systemsearch_column_System%2FType=System%2FType&systemsearch_column_System%2FUser=System%2FUser&systemsearch_column_System%2FVendor=System%2FVendor https://beaker.engineering.redhat.com/?systemsearch-0.table=Key%2FValue&systemsearch-0.keyvalue=CPU_CODENAME&systemsearch-0.operation=contains&systemsearch-0.value=Nehalem&Search=Search&systemsearch_column_System%2FArch=System%2FArch&systemsearch_column_System%2FModel=System%2FModel&systemsearch_column_System%2FName=System%2FName&systemsearch_column_System%2FStatus=System%2FStatus&systemsearch_column_System%2FType=System%2FType&systemsearch_column_System%2FUser=System%2FUser&systemsearch_column_System%2FVendor=System%2FVendor Folks, Why was this bz moved out to Future Feature. This is a big flaw with the way searching should work. Can this be discussed further. The examples I gave were only for the bz this effect many other queries that we use on a day to day bases. Now that RHTS is gone it is much more overhead to track the same things in Beaker. Thanks, Jeff I was thinking about this last night, how you would make this look intuitive. I like the above example. Perhaps I can try an dmimick that with the and/or option. Any progress on this. With so many kernel maintainers now it is a PITA to have so many FF windows open to track the jobs Sorry, no progress has been made towards this. I'd guess that the best chance of getting the kind of functionality you're after is with 860492, although it has not yet been given any target milestone. *** Bug 1328708 has been marked as a duplicate of this bug. *** Team agreed on implementing option that specifies relationship between values. Hello, thank you for opening issue in Beaker project. This issue was marked with component "web ui". As we are not planning to address any further issues in current UI, due to technical stack and not being able to work with Python 3 codebase, I'm closing this issue as WONTFIX. New UI will be reimplemented within new versions of Beaker. If you have any questions feel free to reach out to me. Best regards, Martin <martin.styk> |