Description of problem: When using dependent auto-refresh fields, the displayed values in the service dialog do not match what is processed by the service request. I expect that the values a user sees on the form should be what is processed by the CF server. Here is the scenario where this breaks. Dialog Element Contract - triggers an auto refresh when changed - Contract A - Contract B Dynamic Dialog Element Location - is auto refreshed when Contract changes - If Contract A then display values [Alaska, Ohio] - If Contract B then display values [Florida, Oregon] On initial load the elements are: - Contract A - Alaska If I change the Contract dropdown to Contract B, then the displays are - Contract B - Florida But when I submit the dialog the service request processes the values: - Contract B - Alaska <- value from first dropdown, does not match the form when submitted It appears that the POST requests to dynamic_radio_button_refresh are getting the new values, but when the previously selected value is not available, the selected item in the dialog is changed, but the service provisioning request is not getting updated on the server side. Version-Release number of selected component (if applicable): 5.6.2.2 5.6.3.3 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
I would like to comment on our use case and how this is causing is problems. We have a dialog with fields in the following order: Template (VMware Template Datacenter (VMware Datacenter) Cluster (VMware Cluster) Lifcyce Environment (Dev, Stage, Prod) PCI Checkbox (Is this VM PCI compliant or not) VLAN (VMware vSwitch VLANs and dvSwitch VLANs) The fields have a parent-child relationship from top to bottom. Example, all templates in all datacenters are shown. When the user selects a template, the Datacenter drop-down refreshes and shows only the Datacenters where the template is present. Similarly for Cluster, Lifecycle Environment, PCI and finally VLAN. Why is this causing us issues? It seems that the two fields which are passed incorrectly from Service Dialog to Service Request have been Cluster and VLAN. In the case of Cluster being passed incorrectly, the VM provision fails because CloudForms can't find an available host to place the VM within the Cluster for the selected VLAN. In the case of VLAN being passed incorrectly, the VM provisioning succeeds but is dropped into potentially incorrect security environments. Example a Dev Non-PCI VM is placed into the Production PCI network.
I've tried on both 5.6.2.2 and 5.6.3.3 and I can't reproduce the issue, all of my requests when I switch to B switch to Florida and that is the value that the service request gets when it runs. Can you attach an export of the dialog and the contents of the automate method you're using? Also, regarding https://bugzilla.redhat.com/show_bug.cgi?id=1411541#c2, problem 2 is not intended to be implemented right now. We don't have a way to cascade auto refreshes currently, due to the risk of running into a circular reference, but that kind of functionality is definitely on the radar. Michael, I'll update you once I can actually reproduce, can you also attach your relevant dialog and automate method(s) so I can test with those as well?
Created attachment 1240142 [details] Video of the provlem
Created attachment 1240143 [details] The Automate domain with the dialog code
Created attachment 1240144 [details] The Service Dialog used to test
I opened the original ticket with RH support so I will provide info. I have attached the domain, dialog, and a short video showing what I am seeing. As I went in to reproduce I realized that something wasn't right. I made an assumption about what was happening, but the problem only appears if I have another dynamic dialog after the location. In production, we have around 5 dynamic dialog elements on a form. Once I add a Dynamic Text Area element under location that displays the contract and location and also auto refreshes, it starts behaving as I documented. It is intermittent. As you'll see in the video it seemed to work correctly, but after running through some changes, it got out of sync. Sometimes this happens immediately.
I guess this may come down to the cascading refreshes that you said should not be implemented right now. Unfortunately, without that we really don't have a great way to make sure our user's aren't submitting invalid data. If we rely on them to hit the refresh button and they do it out of order then things go badly quickly. It looks like our only recourse is do make a dropdown that is the combination of the other choices.
Main repo PR: https://github.com/ManageIQ/manageiq-ui-classic/pull/264 Service UI PR: https://github.com/ManageIQ/manageiq-ui-service/pull/503
New PRs: Classic UI - https://github.com/ManageIQ/manageiq-ui-classic/pull/433 Service UI - https://github.com/ManageIQ/manageiq-ui-service/pull/521
Correct values are processed by provisioning request . Verified in 5.8.0.12-rc1.20170425180304_4f35996