Bug 795453

Summary: Previously loaded manifest can not be moved to a new organization.
Product: Red Hat Satellite Reporter: Eric Sammons <esammons>
Component: Subscription ManagementAssignee: Katello Bug Bin <katello-bugs>
Status: CLOSED NOTABUG QA Contact: Katello QA List <katello-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.0.0CC: bkearney
Target Milestone: Unspecified   
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: 795449 Environment:
katello-common-0.1.238-3.el6.noarch katello-headpin-all-0.1.140-2.el6.noarch candlepin-0.5.21-1.el6.noarch
Last Closed: 2012-02-21 17:43:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Bug Depends On: 795449    
Bug Blocks:    

Description Eric Sammons 2012-02-20 15:22:33 UTC 
+++ This bug was initially created as a clone of Bug #795449 +++

Description of problem:
A manifest (M1) loaded into Org 1 (O1) can not be "moved" to oOrg 2 (O2) _after_ M1  in O1 has been overwritten with M2.

Steps to Reproduce:
1. Load a manifest (M1) into Org 1 (O1)
2. Load a _NEW_ manifest (M2) into O1
3. Load M1 into O2
  
Actual results:
Candlepin believes this M1 is already in use; however, it should technically be removed from the db having been overwritten by M2.

Subscription manifest upload for provider 'Red Hat' failed.
Reason: Runtime Error Batch entry 0 update cp_owner set created='2012-02-20 09:50:38.649000 -05:00:00', updated='2012-02-20 09:51:30.960000 -05:00:00', contentPrefix='', displayName='blah', account='blah', parent_owner=NULL, upstream_uuid='0fb93d0e-d868-47c6-9701-f571e9e6a432' where id='8a8b67c7359b39a201359b3e30b900a8' was aborted. Call getNextException to see the cause. at org.postgresql.jdbc2.AbstractJdbc2Statement$BatchResultHandler.handleError:2,598
If you are uploading an older manifest, you can use the Force checkbox to overwrite existing data.

Expected results:
M1 should be available to load in to another org has it has essentially been replaced by M2 in its original org (O1).

Additional Info:
The work-a-round here is to not support the moving of manifests and instead document that sysadmins must generate a new manifest for O2, this manifest could  / should be generated from a new distributor and could have matching QTYs as those in the original Manifest (M1)