Bug 1428905 - Automate Simulation: The simulation form behaves weird after certain steps
Summary: Automate Simulation: The simulation form behaves weird after certain steps
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: UI - OPS
Version: 5.8.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: 5.8.0
Assignee: Martin Hradil
QA Contact: Dmitry Misharov
URL:
Whiteboard: automate:simulation:ui
Depends On:
Blocks: 1434157
TreeView+ depends on / blocked
 
Reported: 2017-03-03 15:08 UTC by Milan Falešník
Modified: 2018-06-01 13:13 UTC (History)
6 users (show)

Fixed In Version: 5.8.0.7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
: 1434157 (view as bug list)
Environment:
Last Closed: 2017-06-12 16:57:23 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Milan Falešník 2017-03-03 15:08:00 UTC
Description of problem:
It happens that certain sequence of steps done in Automate Simulation triggers weird behaviour caused by JS returned from the server having an error page in it.

Version-Release number of selected component (if applicable):
5.8.0.3

How reproducible:
always

Steps to Reproduce:
0. FRESH SESSION (delete cookies/anonymous mode)
1. Log in and go to the Automate Simulation
2. On the screen, simulate InspectMe (without Object Attribute, just keep it None), and that will work. Just for sake of completeness open the user object in the tree and do the simulation again, the user id changes (we know the page was actually changed)
3. Now select an object to throw in the mix. I used an Openshift provider. Simulate with it. The simulation works correctly
4. Now select the Object Attribute Type to be <None>
5. (*)
6. Open the developer console to be able to watch the network requests
7. Press the submit button to do the simulation.
8. (**)
9. You can try reloading the page and it will do the same thing when simulated
10. (***)

Actual results:
(*) The Object Attribute Selection does not disappear
(**) The tree is not updated an inspection of the response contents reveals an error HTML page to be set by the JS (which does not even happen, so that is a bug in a bug :) ). The error that is contained in the $("#center_div").html(...) is "wrong constant name  [miq_ae_tools/resolve]".
(***) After going away and returning, the Object Attribute Selection is now hidden as expected, but the problem in (**) persists.

Expected results:
(*) The Object Attribute Selection disappears
(**), (***) The simulation runs as expected with no error.

Additional info:

Comment 2 Milan Falešník 2017-03-03 15:13:56 UTC
By the way, #center_div is not present on the simulation page, you probably want to target #main-content or something else.

Comment 7 CFME Bot 2017-03-20 15:22:49 UTC
New commit detected on ManageIQ/manageiq-ui-classic/master:
https://github.com/ManageIQ/manageiq-ui-classic/commit/68787b8f2a4d3774d02bd59491900cb4b1f45475

commit 68787b8f2a4d3774d02bd59491900cb4b1f45475
Author:     Martin Hradil <mhradil>
AuthorDate: Fri Mar 17 14:24:34 2017 +0000
Commit:     Martin Hradil <mhradil>
CommitDate: Fri Mar 17 14:25:52 2017 +0000

    MiqAeTools#form_field_changed - don't crash on empty target_class
    
    broken by https://github.com/ManageIQ/manageiq/pull/10060, we need to be able to handle the situation of empty target_class - reset stuff and hide the sub-select when None
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1428905

 app/controllers/miq_ae_tools_controller.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment 9 Milan Falešník 2017-03-29 09:23:20 UTC
Verified in 5.8.0.7 using the steps.


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