Complexity problems with the policy simulation screen

[skateman]

The policy simulation screen is accessible after selecting at least one VM/Template:

After selecting some policy profiles to simulate, the simulation result shows up in the bottom-right quadrants of the quadicons:

Due to the nature of GTLs and report_data, this alteration of quadicons has been implemented in the decorators repo which is fundamentally wrong. I see the following options as solutions:

• Create a meta-activerecord-model for policy-simulated entities with a report yaml and a decorator. It would be a clean solution, as there would be no more conditionals based on globals in the QuadiconHelper but it would require crazy metaprogramming in the decorators repo, not even mentioning the required dark magic for the model and the report.
• Move the global conditional and the quadicon alteration into the report_data. This is not a real solution, just moving bad patterns from A to B. Also the report_data is being used in way too many places, so we might risk of introducing regressions across MiQ.
• Drop the quadicon-based result display and substitute it with something else. This is my favorite idea for now, but it requires UX input (will work on it).
• < Your idea here >

You can access the detailed policy simulation result of each entity by clicking on their quadicons. The results are displayed in the tree:

The problem with this tree is that it has too many extra styling which is really hard to maintain in the codebase. We're sending styled HTML in the nodes' text with html_safe, which is far from being good and it's probably not even supported by our new react trees. Here I see the following options:

• Handle this with the react trees the same way as with the old trees. This would probably require some modifications on the tree component and so we would move the problem into a new framework.
• Introduce mini-components for the styled text and allow them somehow to render from the tree without actually using tags. My imagination is that the TreeBuilder would send some kind of JSON as the nodes' text that the tree component would understand and render it using the mini-components. It would clean the backend, but it adds extra complexity on the frontend.
• Drop the whole thing and create something better than the tree. As the depth of the tree is finite and static, the results can be displayed using some other view. Again, this requires help from UX.
• < Your idea here>

[skateman]

We'll have a meeting about this with @terezanovotna and @hstastna soon, just wanted to write it down somewhere, basically a brain dump.

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 6 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions!

[skateman]

@miq-bot rm_label stale

[miq-bot]

This issue has been automatically marked as stale because it has not been updated for at least 3 months.

If you can still reproduce this issue on the current release or on master, please reply with all of the information you have about it in order to keep the issue open.

Thank you for all your contributions! More information about the ManageIQ triage process can be found in the traige process documentation.

[Fryguy]

Need some UX on this... cc @Ashley-Johnson28