Description of problem: # hammer host list --order id Error: 400 Bad Request The id has not defined ordering on it so the failure is expected but the message is not helpful. The API sends nice message which is not propagated by hammer <pre> [ERROR 2017-11-08 08:20:18 API] 400 Bad Request [DEBUG 2017-11-08 08:20:18 API] { "error" => { "message" => "the field 'id' in the order statement is not valid field for search", "class" => "ScopedSearch::QueryNotSupported" } } </pre> Version-Release number of selected component (if applicable): Hammer 0.11 How reproducible: Always Steps to Reproduce: 1. hammer host list --order id 2. see the ouptut 3. Actual results: Error: 400 Bad Request Expected results: Error: the field 'id' in the order statement is not valid field for search Additional info:
Created redmine issue http://projects.theforeman.org/issues/21627 from this bug
When addressing this, please be sure that the user behavior is consistent regardless of which part of the application is being used. E.g. foreman or plugins (e.g. katello, discovery...etc).
Moving this bug to POST for triage into Satellite 6 since the upstream issue http://projects.theforeman.org/issues/21627 has been resolved.
FailedQA on Sat 6.4 snap 9. 1) Failing this based on comment 2. Although the message is now shown by Hammer, the behavior is inconsistent in the fact that some entities are sortable by id and some are not: # hammer host list --organization-id 1 --order id 400 Bad Request the field 'id' in the order statement is not valid field for search # hammer activation-key list --organization-id 1 --order id [sorted table] 2) Additionally, the message is still not correct: it says 'id is not valid field for search' while I am not attempting to *search*, I am attempting to *order*. That is, however, an issue of what the API itself returns. I can verify this and create a new BZ for issue 1), but as Brad specifically requested consistency check for this, I am failing the BZ for now.
The purpose of the BZ was just to make sure we propagate more info on bad request. I would say both 1) and 2) are valid bugs (although with low prio), but since they are in different component, and the hammer itself was fixed, I would suggest keeping this as verified and filing BZs with the other findings.
Upstream bug assigned to sabnave
Verifying as per comments 6 and 7. Will report mentioned issues as separate BZs.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:2927