Since the number of systems in the SSM is variable, we can't predict how long an operation will take. To avoid timeouts on the page and not lock the user out of the UI for potentially long running operations, some of the SSM UI would benefit from being done asynchronously from the rest of the UI. This BZ is to track the implementation of the DB changes and UI to display running requests. Others will be filed to cover hooking SSM operation up to the mechanism.
Remove bug 483603 blocks bug 483606.
Last Commit: b87ff137cc244b38db19b7b2e8929d85591c60ca This is finished barring any feedback to the e-mail I sent to spacewalk-devel. As a quick summary, I want a way to submit a SSM request and be able to track it by going back to a page of all of these operations rather than sit on a blank page waiting for it to complete. I added a new tab to the SSM tab bar called Operations with two subtabs: In Progress and All. Clicking on an operation description in either of these views brings up a details page that shows some more information about the operation itself along with a list of all servers that were in the SSM at the time the operation was submitted. The links on the server names lead to that server's event history tab so the user can quickly see the status of the request on that particular server (assuming the operation resulted in a server event). Testing this will be done in conjunction with 484285, since it'll be the first way to introduce these sorts of operations into the system. Otherwise, testing should focus around: - Ensuring the operations link appears in the tab bar - Ensuring all of the links between the two lists (in progress and all) as well as to the details page and server events page work - Ensuring that operations triggered by one user do not appear when logged in as another user
Spacewalk 0.5 released.
Spacewalk 0.5 has been released for long time ago.