Bug 1509244

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