Description of problem: User needs to uncheck "Start this VirtualMachine after creation" twice, because after clicking next on the VM customization this option is checked again. Version-Release number of selected component (if applicable): CNV 4.12.1 + OCP 4.12.6 How reproducible: Always Steps to Reproduce: 1. Create Virtual Machine from catalog 2. Pick an entry from the catalog 3. In the quick create dialog, fill in the name and uncheck "Start this VirtualMachine after creation" 4. Click "Customize VirtualMachine" 5. Click Next 6. Now in the "Review and create VirtualMachine", look at the bottom and see "Start this VirtualMachine after creation" is checked/enabled again. Actual results: * "Start this VirtualMachine after creation" not carried over Expected results: * Persist the setting when progressing to new dialogs
I am not sure if this behavior is not by design - checking "Start this VirtualMachine after creation" by default, when reaching some page containing this checkbox. WDYT, Yifat? Can you, please, advice? Thanks!
I think that if a user decided to unselect something, they probably have a reason for that. They continue with the flow and then realize that the selection they just marked is not kept, so they need to uncheck it again. This doesn’t look like a nice user experience, TMO. I think users would expect their selection to be kept, unless they decide to change it (as long as they didn’t click “create”). @gouyang @rsdeor WDYT?
It should be carried over to next page just like the VM name.
Fixing: https://github.com/kubevirt-ui/kubevirt-plugin/pull/1133
I agree, user selection should not be override when moving between pages
verified on 4.13.0
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 (Moderate: OpenShift Virtualization 4.13.0 Images security, bug fix, and enhancement update), 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-2023:3205