Client/Server Custom Buttons


I want to raise the topic of user feed back. Whilst this can be a number of different forms, one particular that comes up is when clicking a custom button.

Use Case : User clicks a custom button, some automate runs, but the result can be passed back to the users browser.

Example : Select a VM, click custom button, automate generates the RDP details for the VM and generates the file for download, posting the link back to the user.

Example : Select a VM, click custom button, automate generates the required URL for a bespoke remote control software, that is posted back to the user in a new window.

I think this request is slightly different to those that request constant feed back to the user, this request is a lot simpler in that user clicks button, automate runs, and returns html back through the web server to the users browser, presumably targeting a frame, or window etc…I would expect the browser to wait for the result to be returned from automate, support normal browser timeout defaults.

thoughts? @dclarizio and others… any other use cases to help?

Custom button action status

Hey John,

In example 1 I assume RDP is Remote Desktop Protocol? What would the “file” contain, the link to start an RDP session with the VM?

It sounds like a good request. Had also thought about this in the past:

Custom button is pressed, automate is run or a dialog is shown, then automate runs and the script can:

  • return a flash message (similar to what the product does) with success (green), warning (yellow), error (red) and the text, which is then displayed on the screen the button was pressed on.
  • return a link within the product to redirect to, such as “show a specific VM” or “show task list”, etc. Of course, we would have to formalize the format of these links.

For any of these, the server would need to know that automate needs to be waited on (async processing), as right now I think it just kicks it off and says " < task > initiated".

. . . Dan


Yes @dclarizio, the format of a RDP file is just clear text, that a bit of automate could generate from VM Insight data, like IP address, hostname etc are required. Now I would want to pass this back as either a file to download or as a url to a file automate just created for the user, either way the user is able to click a custom button and from that they are handed something back from automate. I wondered if automate could be passed an id of a window in the client browser, so that when its finished doing its automate script it can hand back to the root object the client browser window id, so that the CF web server element could return back the data that automate has compiled to the client browser?

The flash message could return “Check you inbox” and we could implement an in product in-box, so that automate could push to there instead of just email, this way it could be real time, where messages can be posted for this user.

Agreed on the wait, and I think this is important, we want when the submit button is pressed that the browser waits for the return, this should be controllerable from the custom button. thanks


We have many uses cases where we add button provide additional functionnalities and feedback on the screen will be really appreciated. For example, we created recently:

  • A button to rezise VM disk, including a Dialog with Drop Down
  • A button to add a Disck
  • A button to change OpenStack Flavors of an instance

In some cases, the methods may fails because for example the disk size you entered is lower than the exist disk, returning on the screen the error with appropriate message will help a lot user experience. Now, we may not want to lock the screen until we send feed back to the user then, a notification mechanism can be aslo a good way to do this! Browser like Chrome have notification mechanism built-in!


I have had to do something similar as @jhardy was suggesting. This was for sending a RHEV virt-viewer file I called up from rest, but then sent the file as an email to the logged on user. A total work-around but did the deed until we have the novnc proxy stuff working for RHEV here in the upcoming release. If we had some sort of in-webapp inbox so you don’t have to depend on the messaging system then it would be a much better option. This was just one of my use cases, but there have been plenty of times I needed to retrieve a file that automate could compile for me and I don’t necessarily want to depend on emails or dumping to an NFS to do this.