Bug 2109699

1. Proposed title of this feature request

[RFE] Add optional filter options to hammer command "hammer content-view version"

2. Who is the customer behind the request?

sysmgmt team

3. What is the nature and description of the request?

I'd like to request that the options be added to hammer:

hammer > content-view > version > filter
hammer > content-view > version > filter > add-repository
hammer > content-view > version > filter > create
hammer > content-view > version > filter > delete
hammer > content-view > version > filter > info
hammer > content-view > version > filter > list
hammer > content-view > version > filter > remove-repository
hammer > content-view > version > filter > rule
hammer > content-view > version > filter > rule > create
hammer > content-view > version > filter > rule > delete
hammer > content-view > version > filter > rule > info
hammer > content-view > version > filter > rule > list
hammer > content-view > version > filter > rule > update
hammer > content-view > version > filter > update

4. Why does the customer need this? (List the business requirements here)

Sometimes customers ask us for help figuring out why their hosts can't see certain content provided by their content views. We can use either hammer or the web interface to see filters that have been applied to the latest version of the content view, but we can't see filters that were applied to older versions of a content view, and that do not apply to the current content view.  If the customer is using multiple content view versions (eg one version for production and one version for non-production), then those versions could have different filters.

However, if we only add the list and info options to content-view > version, then hammer commands will be inconsistent, so I've copied all of the options I see under "content-view > filter" here.

5. How would the customer like to achieve this? (List the functional requirements here)

It would probably require updates to the foreman API.

6. For each functional requirement listed, specify how Red Hat and the customer can test to confirm the requirement is successfully implemented.

Run the new commands and compare the results to what we see in the web interface.

7. Is there already an existing RFE upstream or in Red Hat Bugzilla?

no

8. Does the customer have any specific time-line dependencies and which release would they like to target (i.e. RHEL5, RHEL6)?

no

9. Is the sales team involved in this request and do they have any additional input?

no

10. List any affected packages or components.

foreman

11. Would the customer be able to assist in testing this functionality if implemented?

yes