Description of problem: A method is used to populate a drop down list element in a service dialog, This methods not only gets executed when the service dialog is shown but also when: - the request is approved - The request Version-Release number of selected component (if applicable): How reproducible: Once the service dialog is created, call it, Steps to Reproduce: 1.Create the service dialog, and related. 2.The element settings are: Type: drop down list Dynamic: on Entry Point : /....instance 3. Go to services --> catalogs -->Order At this point the drop down list is shown and the method gets executed, this is expected. 4. click submit 5. Click in the request. At this point the method gets executed again. 6. Click in the V sign to approve the request The method gets executed again 7. type a reason and click submit The method doesn't execute again. 8. In the requests list page, click again in the request The method gets executed again. 9. Go to Automate --> Customization 10. click in the dialog, and 'edit this dialog' The method gets executed again. 11. click in the element The method doesn't get executed. Actual results: The method gets executed when it's not needed. Expected results: The method only gets executed when it's needed. Additional info:
Eric, see comment 2, any chance we can squeeze this into 5.7.2?
Actually, with https://github.com/ManageIQ/manageiq/pull/14219 (which is already backported to Euwe), when viewing the request, that method execution should be gone. I'm not sure about approving the request, but I'll test and find out.
Yes, sorry, this has been fixed with the above PR. The automate method should only be executed once upon starting the order (or if there are manual or auto-refreshes). The requests view should no longer be firing the automate method while viewing or approving.
Checked in 5.8.0.13, I went through the steps with tailing the automation.log and in steps 5, 6, 8 and 10 I can see the requests still happen in the log. It is especially surprising given the fact that in the request details the value is static. I can see the code changes are in place.
Looks like it got changed again to call the .values method, which runs through the automation code. Was changed in https://github.com/ManageIQ/manageiq-ui-classic/pull/1006. Will look more into how to solve this issue while simultaneously solving the issue that PR was meant to address.
So it looks like the reason that last PR exists is because the requests screen is supposed to be displaying the description, rather than the value that was submitted. This is a problem for dynamic dialogs, because when you submit the dialog, only the value is captured, not the description, and so it needs to run through the automate code again in order to obtain the description for the value that was submitted.
Looks like the needinfo got cleared.
Drew - Would suggest working with Erik on this issue. From the ticket description there I would expect that items 10 and 11 can be solved independently and we have run into (and I thought solved) them before. I suspect that other code changes have caused them to reappear. For the remaining items the pattern is likely the same root cause. The dialogs are being redisplayed and do not contain the original field data to properly display both the field "key" and the field "display text". These fields are dynamic the display text value is not persisted anywhere. The dialog loads the data when it is needed from the dynamic method defined in automate. As a possible solution we might want to record the selected values (key & display value) for each field in the miq_request instance when the service is ordered and have a way to recall these values when the dialog is redisplayed as part of the request tab.
*** Bug 1442232 has been marked as a duplicate of this bug. ***