Bug 978728

+++ This bug was initially created as a clone of Bug #975671 +++


+++ This bug was initially created as a clone of Bug #953999 +++

1. Proposed title of this feature request
Modal Error Dialogs in the Admin Console Must Support the Plug-In Model

2. Who is the customer behind the request?
Red Hat 

3. What is the nature and description of the request?
We need to be able to use the UI plug-in framework to insert diagnostic services into any/all modal error dialogs that are rendered by the webadmin console.

4. Why does the customer need this? (List the business requirements here)
Diagnostic services.

5. How would the customer like to achieve this? (List the functional requirements here)
Ensure that all modal error dialogs produced by the webadmin console are compliant with the existing plug-in model.

6. List any affected packages or components.
The Red Hat Support Plug-in for RHEV is adversely affected by the fact that the dialogs are not plug-able.

7. Would the customer be able to assist in testing this functionality if implemented?
Yes.

--- Additional comment from Einav Cohen on 2013-04-19 17:41:09 EDT ---

Keith, just to clarify the requirements here: the idea is to be able to "hook" the ui-plugin that you write to an "Error-Dialog-Popped-Up" event that the ui-plugins infrastructure will supply (and this event should, of course, provide the details of the popped-up error), so that the ui-plugin will be able to perform some action(s) once this event is triggered? 
if so: what kind of action(s) do you wish/plan to "hook" to this event, once introduced to the ui-plugins infrastructure?

--- Additional comment from Keith Robertson on 2013-04-20 09:38:08 EDT ---

(In reply to comment #1)
> Keith, just to clarify the requirements here: the idea is to be able to
> "hook" the ui-plugin that you write to an "Error-Dialog-Popped-Up" event
> that the ui-plugins infrastructure will supply (and this event should, of
> course, provide the details of the popped-up error),

Details are good.  Even if they're not displayable we could still reach into the event object and use them in our search/analysis.

> so that the ui-plugin
> will be able to perform some action(s) once this event is triggered? 
> if so: what kind of action(s) do you wish/plan to "hook" to this event, once
> introduced to the ui-plugins infrastructure?

What we envision is that we can make either the entire error message within the error dialog a hyperlink which is clickable and which would take the user to related solutions or, if we detect that the user is already logged in, we simply analyze the error and show 1-2 possible solutions as links below the actual error message within the error dialog.

Sample flow:
1) Admin user is using webadmin and a modal error dialog pops up in the cluster tab. 
2) We analyze the error and present the top 2 suggestions to the user in the modal error dialog below the actual message
3) If the user clicks on one of the suggestions the modal error dialog will close and we either...
3a) Show them this:   
 https://docspace.corp.redhat.com/servlet/JiveServlet/showImage/102-131571-13-25947/Screen+Shot+2013-03-11+at+4.58.47+PM.png
3b) Or show them this...
 https://docspace.corp.redhat.com/servlet/JiveServlet/showImage/24728/Screen+Shot+2013-02-04+at+11.03.11+AM.png

 
I'd like your thoughts on the best way to *show* them the solution (ie. step 3).  It might not be appropriate to actually show them the solution in the error dialog because error dialogs aren't resizeable and they're generally very small.

Keith

--- Additional comment from  on 2013-05-09 11:56:41 EDT ---

Hi Keith, based on your sample flow in comment #2, here's my design proposal for this feature. Let me know what you think.

---

1. New plugin event handler function called when the error dialog is shown:

api.register({
    ...
    ErrorDialogShown: function(errorMessage) {
        // errorMessage (string) is the message shown in dialog content
    }
    ...
});

Currently, we don't have client-side exception /stacktrace/ information available when the error dialog is shown, simply because the error dialog doesn't need such information. When using WebAdmin in production (non-debug) mode, class metadata is obfuscated as part of GWT compilation, which will mess up the stacktrace information at runtime.

Question: do you need (de-obfuscated) client-side stacktrace information for ErrorDialogShown function, in case the error dialog was triggered due to exception? If the answer is yes, I see two options [1]:
a, preserve some parts of stacktrace information during GWT compilation, however this could increase resulting JavaScript footprint by far
b, pass obfuscated exception to server, do stacktrace de-obfuscation there, pass de-obfuscated stacktrace information back to client

[1] http://www.summa-tech.com/blog/2012/06/11/7-tips-for-exception-handling-in-gwt/

Also related, what about client-side runtime (uncaught) exceptions? Currently, we don't have any special handler for these. Do you think we should also add new plugin event handler function called on runtime exception?

---

2. New plugin API for adding custom hyperlinks to the (currently visible) error dialog:

api.addErrorDialogContentLink('Custom Link Text', {
    onClick: function() {
        // handle link click here
    }
});

The addErrorDialogContentLink API function would have effect only if the error dialog is currently visible.

Note that the error dialog is implemented as singleton (!) so there can be only one instance of this dialog visible at a time. This function would basically extend existing dialog content, i.e. add custom hyperlink below the error message.

This API would be used for both use-cases mentioned by Keith:
- "entire error message within the error dialog a hyperlink" --> can be done via single custom hyperlink
- "show 1-2 possible solutions as links below the actual error message" --> can be done via multiple custom hyperlinks

---

3. New plugin API for closing the (currently visible) error dialog:

api.closeErrorDialog();

The closeErrorDialog API function would have effect only if the error dialog is currently visible.

---

> I'd like your thoughts on the best way to *show* them the solution (ie. step 3)

In "handle link click here" part of addErrorDialogContentLink API function (see above), you could do this:

api.closeErrorDialog();
api.showDialog('Suggested Solution', 'gss-plugin-suggested-solution', url, '800px', '600px', {
    // possibly declare 'Close' dialog button
    // possibly enable dialog resizing
});

---

Regards,
Vojtech