Bug 731390

Summary: Success notification for Promotion comes long after clicking "Promote"
Product: Red Hat Satellite 6 Reporter: Jeff Weiss <jweiss>
Component: WebUIAssignee: Justin Sherrill <jsherril>
Status: CLOSED CURRENTRELEASE QA Contact: Katello QA List <katello-qa-list>
Severity: medium Docs Contact:
Priority: unspecified    
Version: 6.0.1CC: dajohnso, mmccune
Target Milestone: UnspecifiedKeywords: Triaged
Target Release: Unused   
Hardware: Unspecified   
OS: Unspecified   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2012-08-22 17:52:52 UTC Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Bug Depends On:    
Bug Blocks: 747354    

Description Jeff Weiss 2011-08-17 13:55:01 UTC
Description of problem:

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. Create a custom provider and an environment in ACME_Corporation
2. Create 3 products in your provider, with a repo in each one 
3. On the promotions page for Locker, add the 3 products to a new change set.
4. Click Review
5. Click Promote
Actual results:
The "spinner" mouse pointer activates (but you can only notice this if you move the mouse off the "Promote" button - because the "hand" pointer seems to override the "spinner" pointer).  it stays that way for about 10-15 seconds.  Then the page starts to reload.  The page takes about 10 seconds to reload, and then the success notification appears.

Expected results:
Spinner should activate immediately if possible, even when still hovering over the Promote button. Success notification should appear within 10 seconds.

Additional info:

Comment 1 Jeff Weiss 2011-08-17 14:55:57 UTC
Each successive promotion appears to get slower and slower.  I've done 6 or 7 promotions (identical to the original repro steps), and now the time to show the success notification is over 40 seconds.

Comment 2 Justin Sherrill 2011-09-13 21:10:41 UTC
So this behaviour has changed greatly and is now done via an async process. As a result, this issue should not occur anymore.

Comment 3 Jeff Weiss 2011-09-19 19:28:42 UTC

Comment 6 Mike McCune 2013-08-16 18:20:14 UTC
getting rid of 6.0.0 version since that doesn't exist