Bug 1836391

Summary: hammer erratum list --fields does not work for all fields
Product: Red Hat Satellite Reporter: Stephen Wadeley <swadeley>
Component: HammerAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED WORKSFORME QA Contact: Stephen Wadeley <swadeley>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.7.0CC: apatel, kgaikwad, mshira, ofedoren, rabajaj
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2020-06-02 10:36:54 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 Stephen Wadeley 2020-05-15 19:01:32 UTC
Description of problem:

hammer erratum list --organization-id="xx" --fields="id" shows ID column with entries, but:
hammer erratum list --organization-id="xx" --fields="id,errata_id" 
hammer erratum list --organization-id="39" --fields="errata_type"

does not show the errata ID.

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

[root@dhcp-2-39 ~]# rpm -q satellite
satellite-6.7.0-7.el7sat.noarch


[root@dhcp-2-39 ~]# hammer --version
hammer (0.19.2.1)
 * hammer_cli_foreman (0.19.6.4)
 * hammer_cli_foreman_admin (0.0.9)
 * hammer_cli_foreman_ansible (0.3.2)
 * hammer_cli_foreman_azure_rm (unknown version)
 * hammer_cli_foreman_bootdisk (0.3.0)
 * hammer_cli_foreman_discovery (1.0.2)
 * hammer_cli_foreman_docker (unknown version)
 * hammer_cli_foreman_openscap (0.1.8)
 * hammer_cli_foreman_remote_execution (unknown version)
 * hammer_cli_foreman_tasks (unknown version)
 * hammer_cli_foreman_templates (0.1.2)
 * hammer_cli_foreman_virt_who_configure (unknown version)
 * hammer_cli_katello (0.20.2.3)

How reproducible:
every time

Steps to Reproduce:
1. Set up Content Host and CV, with errata
2. Enter: hammer erratum list --organization-id="xx" --fields="id,errata_type"
3.

Actual results:

[root@dhcp-2-39 ~]# hammer -v -u admin -p changeme --output=csv erratum list --errata-restrict-installable="1" --content-view-id="67" --lifecycle-environment-id="66" --organization-id="39" --per-page="10" --fields="id,errata_type"
ID
2

Expected results:

[root@dhcp-2-39 ~]# hammer -v -u admin -p changeme --output=csv erratum list --errata-restrict-installable="1" --content-view-id="67" --lifecycle-environment-id="66" --organization-id="39" --per-page="10" 
ID,Errata ID,Type,Title,Issued,Updated
2,RHSA-2012:0055

Comment 1 Oleh Fedorenko 2020-05-15 20:06:14 UTC
Hello,

The command works just fine. Probably you've wrongly specified fields to display.

To have printed `id` and errata `type` fields only, you need to specify those fields as they are shown in the default output:

> hammer ... --fields 'id,type'

Additional:

By default this command has ID,Errata ID,Type,Title,Issued,Updated fields. This command has not `errata_type` or `errata_id` fields. It's just `type` and `errata id` respectively.

Could you please try again with this information and confirm if this is still a bug?

Comment 2 Stephen Wadeley 2020-05-16 18:12:55 UTC
Hello Oleh

thank you for the quick response.

I confirm 'type' works:

[root@dell-r330-12 ~]# hammer erratum list --fields 'id,type'
-----|------------
ID   | TYPE       
-----|------------
32   | bugfix     
9048 | security  


But I am not getting any thing for:

root@dell-r330-12 ~]# hammer erratum list --fields 'errata_id' 

<blank output>



The help output has these two lines under Search / Order fields:

  errata_id           string
  errata_type         string

that is why I was trying those two values. Its actually the 'errata_id' I wanted to use in a script.


BTW, there is a typo in:

--fields FIELDS                                           Show specified fileds or predefined filed sets only.

s/fileds/fields/ and s/filed/field/

I wanted to make pull request, but could not find that line in the repos:

hammer-cli-katello]$ grep -r "Show specified" .

<no hits>

hammer-cli-foreman]$ grep -r "Show specified" .

<no hits>


Looking in the repo,  in lib/hammer_cli_katello/erratum_info_command.rb, I see:
     field :errata_id, _("Errata ID")
     field :type, _("Type")   

so errata_id should work.

[root@dell-r330-12 ~]# hammer erratum list --fields 'id,errata_id' | head -n 4
----
ID  
----
32 

but does not on my system.

Thank you

Comment 3 Oleh Fedorenko 2020-05-16 19:49:09 UTC
Hello again,

1) Thanks for additional information. As I said (probably not clearly enough, sorry), you need to use labels for --fields option. So, even though in the code the field's id is `errata_id` the label of it is just `errata id` (without the underscore). --fields option uses labels because this is what user can see in the command's output, he cannot see the actual ids.

2) Since this option comes as a default one from the core, you need to search for it in the hammer-cli repo: https://github.com/theforeman/hammer-cli/blob/master/lib/hammer_cli/options/predefined.rb. Thanks for noticing this! We could translate this BZ for this issue if the described one is not an actual issue.

3) Search / Order fields are the fields you can pass to --search/--order options only.

Comment 4 Stephen Wadeley 2020-05-18 07:07:15 UTC
(In reply to Oleh Fedorenko from comment #3)
> Hello again,
> 
> 1) Thanks for additional information. As I said (probably not clearly
> enough, sorry), you need to use labels for --fields option. So, even though
> in the code the field's id is `errata_id` the label of it is just `errata
> id` (without the underscore). --fields option uses labels because this is
> what user can see in the command's output, he cannot see the actual ids.

I confirm that works:

[root@dell-r330-12 ~]# hammer erratum list --fields 'id,errata id'
-----|----------------
ID   | ERRATA ID      
-----|----------------
32   | RHBA-2020:2139 
9048 | RHSA-2020:2081 


So the help out put is confusing.
> 
> 2) Since this option comes as a default one from the core, you need to
> search for it in the hammer-cli repo:
> https://github.com/theforeman/hammer-cli/blob/master/lib/hammer_cli/options/
> predefined.rb. Thanks for noticing this! We could translate this BZ for this
> issue if the described one is not an actual issue.

PR made: https://github.com/theforeman/hammer-cli/pull/331
Fix typo: s/filed/feild/ by swadeley · Pull Request #331 · theforeman/hammer-cli

> 
> 3) Search / Order fields are the fields you can pass to --search/--order
> options only.

Can I make another OR to check:

 these two lines under Search / Order fields:

  errata_id           string
  errata_type         string

to:

  errata id    string
  type         string

oir perhaps you can improve the code to accept both forms?

Thank you

Comment 5 Oleh Fedorenko 2020-05-18 08:25:09 UTC
(In reply to Stephen Wadeley from comment #4)
> 
> 
> So the help out put is confusing.
So, I'd suggest to improve help as part of the https://bugzilla.redhat.com/show_bug.cgi?id=1829701. Feel free to add in the comments what should be improved additionally.
> 
> PR made: https://github.com/theforeman/hammer-cli/pull/331
> Fix typo: s/filed/feild/ by swadeley · Pull Request #331 ·
> theforeman/hammer-cli
This was merged, thanks! 

> Can I make another OR to check:
> 
>  these two lines under Search / Order fields:
> 
>   errata_id           string
>   errata_type         string
> 
> to:
> 
>   errata id    string
>   type         string
> 
> oir perhaps you can improve the code to accept both forms?
I would have not mixed those two cases. --fields options was designed to use labels as those are shown to users. So a user can arrange what he/she sees without further knowledge. Hidden fields' ids may not be in sync with their labels, e.g. :errata_type vs "Type". And I'd like to leave it this way. Otherwise we would need to refactor a lot of code across all the hammer plugins which is quite unnecessary to accept field ids instead of labels (or to sync them).

Search/Order fields are coming from the server models' definitions. If we will accept both forms it may cause errors such as showing incorrect or undesirable field.

Comment 6 Oleh Fedorenko 2020-06-02 10:36:54 UTC
Closing this one, since the issue here is more about help output and wrong usage. If you think that this is still a relevant bug, please reopen. Otherwise, use https://bugzilla.redhat.com/show_bug.cgi?id=1829701 for additional suggestions regarding help improvement.