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.
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...
*** Bug 667451 has been marked as a duplicate of this bug. ***
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 ?
(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.
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.
Ed, Can you provide more details? I won't start on this until then.
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.