Skip to content

Conversation

@adamruzicka
Copy link
Contributor

@adamruzicka adamruzicka commented Oct 10, 2025

Copy link
Member

@ofedoren ofedoren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @adamruzicka, LGTM, just one inline comment:


class InfoCommand < HammerCLIForeman::InfoCommand
output ListCommand.output_definition do
HammerCLIForeman::References.taxonomies(self)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This information is still "there". WDYT about including it, but since it's on a different level, we could do it in two ways:

  1. Show at the same level to be "compatible" with the changes:
      from :role do
        collection :locations, _("Locations"), numbered: false, hide_blank: true do
          custom_field Fields::Reference, name_key: :title
        end
        collection :organizations, _("Organizations"), numbered: false, hide_blank: true do
          custom_field Fields::Reference, name_key: :title
        end
      end
  1. Include it at role level, but this would require some additional changes:
      field :role, _("Role"), Fields::Reference, details: [
        { key: :locations, structured_label: _('Locations'), except: :serialized },
        { key: :organizations, structured_label: _('Organizations'), except: :serialized }
      ], display_field_key: :name

and then in lib/hammer_cli_foreman/output/formatters.rb:36:

# ...
# The second check is for `base` adapter, since it's quite limited and this is a quick workaround instead of adding a better handler for nested structures (which I'm not sure we want for `base` though)
next if (detail[:id] && !show_ids) || (required_features & Array(detail[:except])).any?
# ...

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

"same level" meaning showing it as if it was a attribute of the filter itself?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeap. Maybe include in the label (inherited), but that wouldn't as "compatible" then :/

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Went with this

# hammer filter info --id 338
Id:                        338
Resource type:             Location
Search:                    none
Role:                      zGptuCUriW
Permissions:               view_locations, assign_locations
Created at:                2025/10/10 09:52:59
Updated at:                2025/10/10 09:52:59
Locations (inherited):
    DVAErp
Organizations (inherited):
    GxRhDkKoNeDD

Copy link
Member

@ofedoren ofedoren left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks, @adamruzicka, I think this is ready.

@ofedoren
Copy link
Member

The main PR is merged, thus merging, thanks, @adamruzicka !

@ofedoren ofedoren merged commit 31744f8 into theforeman:master Oct 16, 2025
5 checks passed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants