Bug 1509244 - Save and Reset button disable on Volume restore form Backup Detail page
Summary: Save and Reset button disable on Volume restore form Backup Detail page
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: 5.10.0
Assignee: Scott Seago
QA Contact: Nikhil Dhandre
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2017-11-03 12:06 UTC by Nikhil Dhandre
Modified: 2019-02-07 23:00 UTC (History)
8 users (show)

Fixed In Version: 5.10.0.0
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-02-07 23:00:36 UTC
Category: ---
Cloudforms Team: Openstack
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2019:0212 None None None 2019-02-07 23:00:47 UTC

Comment 2 Dave Johnson 2017-11-16 16:41:59 UTC
This this is on OSP, please kick back if not.

Comment 3 Scott Seago 2018-05-07 13:48:12 UTC
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.

Comment 5 Scott Seago 2018-05-08 12:48:37 UTC
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.

Comment 6 Nikhil Dhandre 2018-05-11 06:30:58 UTC
(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.

Comment 7 CFME Bot 2018-05-14 08:28:12 UTC
New commit detected on ManageIQ/manageiq-ui-classic/master:

https://github.com/ManageIQ/manageiq-ui-classic/commit/34bddd882bdf172bbf135e5910f633b479ce6608
commit 34bddd882bdf172bbf135e5910f633b479ce6608
Author:     Scott Seago <sseago@redhat.com>
AuthorDate: Mon May  7 22:34:49 2018 -0400
Commit:     Scott Seago <sseago@redhat.com>
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(-)

Comment 8 Nikhil Dhandre 2018-07-03 14:56:36 UTC
Verified with Version 5.10.0.2.20180626170006_40dc459 both buttons working properly.

Comment 9 errata-xmlrpc 2019-02-07 23:00:36 UTC
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


Note You need to log in before you can comment on or make changes to this bug.