Bugzilla will be upgraded to version 5.0. The upgrade date is tentatively scheduled for 2 December 2018, pending final testing and feedback.
Bug 586944 - Can't filter by multiple job numbers
Can't filter by multiple job numbers
Status: CLOSED WONTFIX
Product: Beaker
Classification: Community
Component: command line (Show other bugs)
0.5
All Linux
low Severity medium (vote)
: 0.7.04
: ---
Assigned To: Raymond Mancy
: FutureFeature
: 667451 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-28 10:44 EDT by Alexander Todorov
Modified: 2014-12-07 20:02 EST (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2012-09-25 20:32:22 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Alexander Todorov 2010-04-28 10:44:46 EDT
Description of problem:
I can't select multiple jobs in the job search page when specifying multiple job numbers. I have:

id is 105
id is 637

but no search results shown. if I remove any of these fields Beaker shows the specified job. 

id is 637, 105 shows only Job 637.

Version-Release number of selected component (if applicable):
Version - 0.5.30 

How reproducible:
Always


It would be nice to have AND/OR operator between the fields that are in the filter. Field groups are also something to consider, i.e. (X and Y) or (Z and W).

For my particular case a simple "id is in <list of comma separated values>" will do the job.
Comment 1 Bill Peck 2010-04-28 10:57:15 EDT
Ray,

Not sure if the in list would be easier that Alexander is suggesting or do or's between the same column.  The in list would work for is or is not.  But not sure how that would work for contains...
Comment 2 Raymond Mancy 2011-01-06 00:07:37 EST
*** Bug 667451 has been marked as a duplicate of this bug. ***
Comment 3 Raymond Mancy 2011-10-11 08:53:01 EDT
Treating it as an 'in' would not really be suitable, I think we would have to use and/or. If we want to go down the road and do more advanced logic as Alexander mentions, I'm not sure how easy it's going to be to model that in a nice way in it's current form. XML might be an easier way (definitely easier to implement), but would users be happy to write up some XML for (perhaps) a one off search ?
Comment 4 Bill Peck 2011-10-11 13:30:57 EDT
(In reply to comment #3)
> Treating it as an 'in' would not really be suitable, I think we would have to
> use and/or. If we want to go down the road and do more advanced logic as
> Alexander mentions, I'm not sure how easy it's going to be to model that in a
> nice way in it's current form. XML might be an easier way (definitely easier to
> implement), but would users be happy to write up some XML for (perhaps) a one
> off search ?

Even if we don't use xml on the web page I would like to see us use xml on the server side.  right now we have two different search methods, one in xml and one in webUI.  And there are some things available in one and not the other.

It would also be handy to be able to "build" a search on the webui and then use the XML it built in a job.
Comment 5 Edward Rousseau 2011-10-11 13:43:07 EDT
Note that a more unified "filter" method is in the works cross tool so any UI / search update should be in line with that (to save rework later). I also agree with Bill above moving to a single search method would be preferable.
Comment 6 Raymond Mancy 2011-10-11 19:22:54 EDT
Ed, Can you provide more details? I won't start on this until then.
Comment 7 Raymond Mancy 2012-09-25 20:32:22 EDT
These advanced queries would need to be taken care of by an xml query input. The first part of this is bringing the hostRequires of the job workflow upto par with the UI search. We will then merge the codepaths, which will allow xml query input.

Note You need to log in before you can comment on or make changes to this bug.