Bug 710230

Summary: as5 plugin: The result of invoking an operation can be misleading or confused with the actual result of the operation
Product: [Other] RHQ Project Reporter: Larry O'Leary <loleary>
Component: PluginsAssignee: RHQ Project Maintainer <rhq-maint>
Status: NEW --- QA Contact: Mike Foley <mfoley>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.0.1CC: hbrock, hrupp, jshaughn
Target Milestone: ---Flags: jshaughn: needinfo? (ccrouch)
Target Release: ---   
Hardware: All   
OS: All   
See Also: https://bugzilla.redhat.com/show_bug.cgi?id=754861
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 726178 726780 (view as bug list) Environment:
EAP_EWP 5.1.0 - admin-console
Last Closed: 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: 678340, 745494    
Description Flags
Screen shot of admin-console showing confusion when invoking the Test Connection operation on a datasource none

Description Larry O'Leary 2011-06-02 14:32:57 EDT
Created attachment 502598 [details]
Screen shot of admin-console showing confusion when invoking the Test Connection operation on a datasource

In some cases, the result of invoking an operation can be confused with the result of the actual operation. 

For example:

For a datasource resource, you can invoke the "Test Connection" operation. Once the operation has been submitted, the "Operation History" will indicate "Successful". This "Successful" message can easily be interrupted as the connection to the datasource was successful when in reality, the actual test of the datasource connection returned failed. 

This is confusing to operational admins looking at this UI to test a connection. In fact, this would mislead them to look at the wrong section and proceed thinking the connection has been obtained when it's not, and could possibly cause serious production ramifications. The UI should be re-worked and be more intuitive and clear.
Comment 1 Ian Springer 2011-07-27 14:36:02 EDT
The fix for this should be to improve the description of the 'testConnection' operation in the as5 plugin descriptor as follows:

    <operation name="testConnection" displayName="Test Connection" description="Test if a connection can be obtained - returns true if a connection was obtained, or false if not; NOTE: this operation will always return a status of Successful - the results of the operation must be inspected to see whether or not a connection was obtained">
Comment 2 Ian Springer 2011-07-28 12:59:14 EDT
Fixed in AdminConsole_EAP_5_1 branch - commit f1bb1cc.

This is not possible to verify directly - QE should just do an overall smoke test of the admin-console and make sure all the basics still work.
Comment 3 Ian Springer 2011-07-29 15:06:36 EDT
Fixed in master - commit 5f9ddb7.
Comment 4 Mike Foley 2011-07-29 15:15:08 EDT
discussed with ips:  verification is to be performed by EAP QA
Comment 5 Larry O'Leary 2011-08-09 16:56:38 EDT
(In reply to comment #3)
> Fixed in master - commit 5f9ddb7.

I do not see 5f9ddb7, did you mean e431028f?

Also, please note that this doesn't truly resolve this BZ. It resolves the example use-case provided but the BZ is more general then that. It seems that this confusion can exist with any operation that would have a boolean result. Instead of using the "Success" status on the operation status, maybe we should be looking at:

In Progress --> [Failed | Complete]

Or even going as far as displaying the operations result as the state. If a boolean, "True|False", if a simple object "<object>.toString()", if a complex object, "Object Name" or "See Result" link.

The idea is that we want to convey to the user, via the UI, that what they are looking at is not the result of the operation but a link that will take you to the result of the operation.
Comment 7 Ian Springer 2011-08-09 17:34:08 EDT
Yes, the commit to master should be e431028f. I have no idea where I got that other SHA from.
Comment 8 Charles Crouch 2011-10-18 08:25:09 EDT
I think we should investigate whether a still better solution is possible for 
the Test Connection case. In that particular instance we should investigate 
simply making the operation return a failure status if the internal call to the 
AS to test the connection fails.
Comment 10 JBoss JIRA Server 2012-11-13 06:15:40 EST
Jan Martiska <jmartisk@redhat.com> updated the status of jira JBPAPP-6260 to Closed
Comment 11 JBoss JIRA Server 2012-11-13 06:15:40 EST
Jan Martiska <jmartisk@redhat.com> made a comment on jira JBPAPP-6260

This is fixed in EAP 5.1.2.
Comment 12 Jay Shaughnessy 2013-02-26 16:43:18 EST
"Completed" may be the best thing to do here.  Asking ccrouch for direction on this one.