create keypair displays refresh page after submit, refresh stays on create keypair page instead of going back to main access and security page
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
OpenStack Dashboard (Horizon) |
Fix Released
|
High
|
Tres Henry |
Bug Description
-----UPDATE------
When you create a keypair, the successful response from the view is an attached file, not an HTML page.
Thus, when you create a keypair from the modal window, you get back a file but the modal doesn't close, and the data in the table doesn't update.
Currently a notification pops up reminding you to refresh the page, but this is a lame stopgap fix.
The real problem is that simply closing the window and refreshing the table causes a race condition with nova's keypair creation code, and may refresh before the new keypair data is ready.
Doing the call via AJAX allows you to know when the data is ready, but there is no good javascript file handling mechanism to save the file that's returned.
FIX: uncertain.
----ORIGINAL REPORT------
When creating a keypair the after submit it displays the message "Info: The data on this page may have changed, click here to refresh it." The link that the message goes to is the create keypair form. This should go to the access and security page instead of refreshing a blank form of the same that was just submitted.
Goto system panel -> access & security
select "create new keypair"
enter name and submit
after download is popped up the page displays a message stating to refresh. Clicking the refresh link will display a new blank create keypair form.
Expected:
to be redirected back to the access and security page.
Changed in horizon: | |
milestone: | essex-3 → essex-4 |
description: | updated |
Changed in horizon: | |
status: | Confirmed → In Progress |
Changed in horizon: | |
status: | Fix Committed → Fix Released |
Changed in horizon: | |
milestone: | essex-4 → 2012.1 |
This is a tricky one due to the actual request returning a file rather than a redirect... I tried for a while to make this behavior work intelligently for both the modal dialog behavior and the static page behavior without luck. Agreed that it should be fixed, just warning that the fix is difficult.