Bug 796096 - All bottom buttons get disabled after creating child resource
Summary: All bottom buttons get disabled after creating child resource
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: RHQ Project
Classification: Other
Component: Core UI
Version: 4.3
Hardware: Unspecified
OS: Unspecified
medium
low
Target Milestone: ---
: JON 3.1.0
Assignee: John Mazzitelli
QA Contact: Mike Foley
URL:
Whiteboard:
Depends On:
Blocks: rhq-uxd 803870
TreeView+ depends on / blocked
 
Reported: 2012-02-22 10:02 UTC by Libor Zoubek
Modified: 2015-11-02 00:42 UTC (History)
3 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 803870 (view as bug list)
Environment:
Last Closed: 2013-09-03 15:09:16 UTC
Embargoed:


Attachments (Terms of Use)

Description Libor Zoubek 2012-02-22 10:02:35 UTC
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 17:13:03 UTC
triage 2/27/2012 mfoley, asantos, crouch, loleary

Comment 2 John Mazzitelli 2012-03-15 15:44:46 UTC
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 18:29:56 UTC
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 18:33:08 UTC
(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 18:58:25 UTC
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 19:02:14 UTC
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 15:09:16 UTC
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.