Bug 795449

Summary: Previously loaded manifest can not be moved to a new organization.
Product: [Retired] Subscription Asset Manager Reporter: Eric Sammons <esammons>
Component: candlepinAssignee: Bryan Kearney <bkearney>
Status: CLOSED NOTABUG QA Contact: Eric Sammons <esammons>
Severity: medium Docs Contact:
Priority: medium    
Version: 1.0.0   
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 795453 (view as bug list) 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:44:11 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:    
Bug Blocks: 795453    

Description Eric Sammons 2012-02-20 15:10:29 UTC 
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)