Bug 991447 - Cloning a existing content-view definition doesn't clone the applied filters
Summary: Cloning a existing content-view definition doesn't clone the applied filters
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Satellite
Classification: Red Hat
Component: WebUI
Version: Nightly
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: Unspecified
Assignee: Brad Buckingham
QA Contact: Sachin Ghai
URL:
Whiteboard:
Depends On: 1090643
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-08-02 12:25 UTC by Sachin Ghai
Modified: 2019-09-26 17:43 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2014-09-11 12:29:38 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Sachin Ghai 2013-08-02 12:25:20 UTC
Description of problem:
I created a content view (CV) definition e.g. cv1, then selected a repo from content tab and finally publish it after applying some filters.

However when i cloned the cv1, the applied filters are not actually copied over.

Version-Release number of selected component (if applicable):
katello-1.4.2-1.git.970.aad75f0.el6.noarch

How reproducible:
always

Steps to Reproduce:
1. create a new content-view definition
2. select the product/repo from content tab
3. apply filters and publish it
3. clone the created definition

Actual results:
The cloned definition doesn't contain the applied filters

Expected results:
The applied filters should copy over to cloned definition

Additional info:

Comment 1 RHEL Program Management 2013-09-17 04:21:02 UTC
Since this issue was entered in Red Hat Bugzilla, the release flag has been
set to ? to ensure that it is properly evaluated for this release.

Comment 4 Brad Buckingham 2013-09-19 13:00:37 UTC
katello pull request: 

https://github.com/Katello/katello/pull/3001

Comment 7 Mike McCune 2013-10-17 21:02:58 UTC
Moving this to be tested during MDP3, not critical for MDP2 success story

Comment 8 Og Maciel 2014-04-23 20:46:00 UTC
This is currently blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1090643

Comment 9 Kedar Bidarkar 2014-05-12 14:38:02 UTC
I believe this needs to be in MODIFIED state as we have no build with cv clone exposed. Moving it to MODIFIED state.

Comment 11 Adam Saleh 2014-05-22 12:35:03 UTC
Still blocked by https://bugzilla.redhat.com/show_bug.cgi?id=1090643

Comment 13 Sachin Ghai 2014-05-23 12:03:11 UTC
@Jason Montleon : To verify this bug we need CV clone feature in compose. So far I didn't see clone functionality in any beta compose. So moving this again to modified state.

Comment 14 Brad Buckingham 2014-05-23 14:51:44 UTC
Moving this back to 'assigned'.  When the the content views UI was re-implemented, the clone feature was not brought forward.  It will, however, be added at a later date.

Comment 15 Brad Buckingham 2014-07-02 13:26:38 UTC
With the content view rework 'content view definition's no longer exist; however, it should be possible now to 'copy' a content view.  This operation is similar to the past implementation, in that it will allow the user to a new content view from an existing one.  It will copy over all information, except for history,  tasks and versions.

Comment 17 sthirugn@redhat.com 2014-08-08 18:42:19 UTC
Verified. Now cloning a content view (Copy View) copies the filters as well.

Version Tested:
GA Snap 4 - Satellite-6.0.4-RHEL-6-20140806.0

* apr-util-ldap-1.3.9-3.el6_0.1.x86_64
* candlepin-0.9.19-1.el6_5.noarch
* candlepin-scl-1-5.el6_4.noarch
* candlepin-scl-quartz-2.1.5-5.el6_4.noarch
* candlepin-scl-rhino-1.7R3-1.el6_4.noarch
* candlepin-scl-runtime-1-5.el6_4.noarch
* candlepin-selinux-0.9.19-1.el6_5.noarch
* candlepin-tomcat6-0.9.19-1.el6_5.noarch
* elasticsearch-0.90.10-4.el6sat.noarch
* foreman-1.6.0.38-1.el6sat.noarch
* foreman-compute-1.6.0.38-1.el6sat.noarch
* foreman-gce-1.6.0.38-1.el6sat.noarch
* foreman-libvirt-1.6.0.38-1.el6sat.noarch
* foreman-ovirt-1.6.0.38-1.el6sat.noarch
* foreman-postgresql-1.6.0.38-1.el6sat.noarch
* foreman-proxy-1.6.0.23-1.el6sat.noarch
* foreman-selinux-1.6.0.4-1.el6sat.noarch
* foreman-vmware-1.6.0.38-1.el6sat.noarch
* katello-1.5.0-28.el6sat.noarch
* katello-ca-1.0-1.noarch
* katello-certs-tools-1.5.6-1.el6sat.noarch
* katello-installer-0.0.57-1.el6sat.noarch
* openldap-2.4.23-34.el6_5.1.x86_64
* pulp-katello-0.3-3.el6sat.noarch
* pulp-nodes-common-2.4.0-0.30.beta.el6sat.noarch
* pulp-nodes-parent-2.4.0-0.30.beta.el6sat.noarch
* pulp-puppet-plugins-2.4.0-0.30.beta.el6sat.noarch
* pulp-puppet-tools-2.4.0-0.30.beta.el6sat.noarch
* pulp-rpm-plugins-2.4.0-0.30.beta.el6sat.noarch
* pulp-selinux-2.4.0-0.30.beta.el6sat.noarch
* pulp-server-2.4.0-0.30.beta.el6sat.noarch
* python-ldap-2.3.10-1.el6.x86_64
* ruby193-rubygem-net-ldap-0.3.1-3.el6sat.noarch
* ruby193-rubygem-runcible-1.1.0-2.el6sat.noarch
* sssd-ldap-1.11.5.1-3.el6.x86_64

Comment 19 Bryan Kearney 2014-09-11 12:29:38 UTC
This was delivered with Satellite 6.0 which was released on 10 September 2014.


Note You need to log in before you can comment on or make changes to this bug.