Bug 796096 - All bottom buttons get disabled after creating child resource
All bottom buttons get disabled after creating child resource
Status: CLOSED CURRENTRELEASE
Product: RHQ Project
Classification: Other
Component: Core UI (Show other bugs)
4.3
Unspecified Unspecified
medium Severity low (vote)
: ---
: JON 3.1.0
Assigned To: John Mazzitelli
Mike Foley
:
Depends On:
Blocks: rhq-uxd 803870
  Show dependency treegraph
 
Reported: 2012-02-22 05:02 EST by Libor Zoubek
Modified: 2015-11-01 19:42 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 803870 (view as bug list)
Environment:
Last Closed: 2013-09-03 11:09:16 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Libor Zoubek 2012-02-22 05:02:35 EST
Version-Release number of selected component (if applicable):
Version: 3.0.1.GA
Build Number: dd8a001:fbca611
GWT Version: 2.0.4
SmartGWT Version: 2.4

How reproducible:always on firefox 3.6.24 and chromium 17


Steps to Reproduce:
1. have EAP5 in inventory
2. go to EAP5 resource, Inventory tab and create new child
3. upload some WAR, finish wizard
  
Actual results:All buttons on the bottom [Delete,Import,Create Child,Uninventory,Refresh] are disabled, so user cannot hit refresh to see if the child was deployed successfully.


Expected results: Running 'Create Child' wizard should not affect bottom buttons like 'Refresh' which should be enabled


Additional info: this is a minor issue
Comment 1 Mike Foley 2012-02-27 12:13:03 EST
triage 2/27/2012 mfoley, asantos, crouch, loleary
Comment 2 John Mazzitelli 2012-03-15 11:44:46 EDT
this is yet another place we missed when we changed something in the component implementation. should be easy to fix though.
Comment 3 John Mazzitelli 2012-03-15 14:29:56 EDT
this is strange - this has been fixed in master for quite some time... see commit 85882c6e0e00d5d788032d9c4192577c21e4fcc6 done in august 2011.
Comment 4 John Mazzitelli 2012-03-15 14:33:08 EDT
(In reply to comment #3)
> this is strange - this has been fixed in master for quite some time... see
> commit 85882c6e0e00d5d788032d9c4192577c21e4fcc6 done in august 2011.

Ok, I confirmed this is in master but NOT in release/jon3.0.x branch.

We would need to cherry pick 85882c6e0e00d5d788032d9c4192577c21e4fcc6 to fix this.
Comment 5 John Mazzitelli 2012-03-15 14:58:25 EDT
this was fixed in the release/3.0.x branch, but the following commit undid that fix and reintroduced the bug:

http://git.fedorahosted.org/git/?p=rhq/rhq.git;a=commitdiff;h=0d4efdc85ef65f6cdcf7954766cd28186a36ab63
Comment 6 Charles Crouch 2012-03-15 15:02:14 EDT
Setting Target Release to be JON3.1.0 and setting to ONQA since its now fixed in master.
Comment 7 Heiko W. Rupp 2013-09-03 11:09:16 EDT
Bulk closing of old issues in VERIFIED state.

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