Bug 1412963

Summary:	A method in a dynamically populated drop down list element gets executed without being really needed
Product:	Red Hat CloudForms Management Engine	Reporter:	Raul Mahiques <rmahique>
Component:	Automate	Assignee:	drew uhlmann <duhlmann>
Status:	CLOSED INSUFFICIENT_DATA	QA Contact:	Milan Falešník <mfalesni>
Severity:	high	Docs Contact:
Priority:	high
Version:	5.7.0	CC:	akarol, cpelland, dajohnso, eclarizi, gmccullo, jhardy, jocarter, mfalesni, mfeifer, mkanoor, obarenbo, simaishi, tfitzger
Target Milestone:	GA	Keywords:	TestOnly, ZStream
Target Release:	5.9.0
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:	automate:dialog:ui
Fixed In Version:		Doc Type:	If docs needed, set a value
Doc Text:		Story Points:	---
Clone Of:
Clones:	1446664 (view as bug list)		Environment:
Last Closed:	2017-08-31 15:39:19 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1446664

Description Raul Mahiques 2017-01-13 09:36:56 UTC

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:

Comment 3 Dave Johnson 2017-03-16 05:31:47 UTC

Eric, see comment 2, any chance we can squeeze this into 5.7.2?

Comment 4 eclarizi 2017-03-16 17:14:00 UTC

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.

Comment 6 eclarizi 2017-04-26 16:16:51 UTC

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.

Comment 8 Milan Falešník 2017-05-04 09:09:44 UTC

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.

Comment 9 eclarizi 2017-05-08 18:22:07 UTC

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.

Comment 10 eclarizi 2017-05-30 15:28:13 UTC

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.

Comment 14 Marianne Feifer 2017-08-03 18:02:58 UTC

Looks like the needinfo got cleared.

Comment 15 Greg McCullough 2017-08-14 14:58:09 UTC

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.

Comment 16 lgalis 2017-08-29 18:20:51 UTC

*** Bug 1442232 has been marked as a duplicate of this bug. ***