This this is on OSP, please kick back if not.
I had one question to clarify the behavior you're seeing. If you choose a different volume, do the save and reset buttons get enabled? If so, are they still enabled when you go back and pick the original volume? What I'm seeing in my dev environment is that when the form first comes up, those buttons are disabled, but once I change the selected volume, from that point forward it works fine. So this seems to be a form initialization bug that I need to track down, especially since if there's only one volume available, the "choose something else first" workaround may not even work. I wanted to make sure that this was what you were seeing, or whether in your test environment, those buttons are always disabled, even upon making different selections.
https://github.com/ManageIQ/manageiq-ui-classic/pull/3911
The associated PR resolves the problem with the Save button being initially disabled. My assumption for now is that for the case that reproduces this bug, after choosing a different volume, the save button was already working fine. The reset button will still be disabled on the initial form load -- if the user hasn't done anything yet, there's nothing to reset to.
(In reply to Scott Seago from comment #3) > I had one question to clarify the behavior you're seeing. If you choose a > different volume, do the save and reset buttons get enabled? If so, are they > still enabled when you go back and pick the original volume? What I'm seeing > in my dev environment is that when the form first comes up, those buttons > are disabled, but once I change the selected volume, from that point forward > it works fine. Yes scott, I am agreed with your finding. I tested it and found that when I select others then save button enable for all. > > So this seems to be a form initialization bug that I need to track down, > especially since if there's only one volume available, the "choose something > else first" workaround may not even work. I wanted to make sure that this > was what you were seeing, or whether in your test environment, those buttons > are always disabled, even upon making different selections.
New commit detected on ManageIQ/manageiq-ui-classic/master: https://github.com/ManageIQ/manageiq-ui-classic/commit/34bddd882bdf172bbf135e5910f633b479ce6608 commit 34bddd882bdf172bbf135e5910f633b479ce6608 Author: Scott Seago <sseago> AuthorDate: Mon May 7 22:34:49 2018 -0400 Commit: Scott Seago <sseago> CommitDate: Mon May 7 22:34:49 2018 -0400 bz 1509244: Don't require form changes in order to submit backup restore https://bugzilla.redhat.com/show_bug.cgi?id=1509244 The 'save' button in the backup restore form wasn't active until the user first selected a different volume. To restore to the current volume required changing to a different volume and then re-selecting the original. This commit removes the requirement to change the form first before submitting. Such a requirement makes sense for an edit form (no changes, no need to submit), but it does not make sense for an action form like this. app/assets/javascripts/controllers/cloud_volume_backup/cloud_volume_backup_form_controller.js | 4 +- 1 file changed, 3 insertions(+), 1 deletion(-)
Verified with Version 5.10.0.2.20180626170006_40dc459 both buttons working properly.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:0212