Bug 1565845 - Service buttons do not attach $evm.root['service']
Summary: Service buttons do not attach $evm.root['service']
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: API
Version: 5.9.0
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.9.3
Assignee: Tina Fitzgerald
QA Contact: Shveta
: 1583782 (view as bug list)
Depends On: 1574774
TreeView+ depends on / blocked
Reported: 2018-04-10 22:13 UTC by Jeff Warnica
Modified: 2018-07-12 13:14 UTC (History)
14 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2018-07-12 13:14:16 UTC
Category: ---
Cloudforms Team: CFME Core
Target Upstream Version:

Attachments (Terms of Use)
From classic UI (281.78 KB, image/png)
2018-04-11 16:58 UTC, Jeff Warnica
no flags Details
From self service UI (169.05 KB, image/png)
2018-04-11 16:59 UTC, Jeff Warnica
no flags Details
SUI log run screenshot (121.24 KB, image/png)
2018-05-24 18:04 UTC, drew uhlmann
no flags Details
CUI run screenshot (99.80 KB, image/png)
2018-05-24 18:04 UTC, drew uhlmann
no flags Details
the right screenshot :{ (390.53 KB, image/png)
2018-05-24 18:18 UTC, drew uhlmann
no flags Details
Edit button on Service object (185.31 KB, image/png)
2018-05-31 17:30 UTC, Tsai Li Ming
no flags Details
Logs from going into the dialog form and clicking refresh button (187.17 KB, image/png)
2018-05-31 17:31 UTC, Tsai Li Ming
no flags Details

System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHSA-2018:2184 0 None None None 2018-07-12 13:14:52 UTC

Description Jeff Warnica 2018-04-10 22:13:55 UTC
Per summary, a button attached to a service does not attach to  $evm.root['service'] in automate, as it does for the classic UI.

Comment 2 Chris Hale 2018-04-11 16:13:59 UTC
Hi Jeff,
    Could you provide steps to reproduce this issue and possible screenshots if applicable?  I am not sure this issue is currently assigned under the correct component.  Thank you in advance

Comment 3 Jeff Warnica 2018-04-11 16:58:47 UTC
Created attachment 1420469 [details]
From classic UI

Comment 4 Jeff Warnica 2018-04-11 16:59:12 UTC
Created attachment 1420470 [details]
From self service UI

Comment 5 Chris Hale 2018-04-11 17:18:32 UTC
Thank you for the screenshots Jeff.  I think this might be an issue at the API level of the application.  Before I go ahead and moved the ticket over to them for investigation, do you have an appliance I can look at that reproduces this issue, just so I can inspect that we are in fact sending the service ID when a custom button is submitted?   Thank you for your help.

Comment 9 Chris Hale 2018-04-17 18:13:05 UTC
Hi Jeff.  We are working on reproducing this issue.  Can you provide more steps and instructions on the service custom button you were testing so we can reproduce it in a development environment?

Comment 10 Jeff Warnica 2018-04-17 18:23:32 UTC
It was an extremely basic setup. 

* Create a dialog with a dynamic dropdown
* Dynamic drop down calls an automate method that does dump_root()
* Create a button and connect to services
* Open dialog through button in service in SSUI & OpsUi
* Note difference in logs

Comment 15 Tina Fitzgerald 2018-05-02 18:57:48 UTC
This works properly in the build.

I get the same results running the custom button from the OPSUI and SUI.

----] I, [2018-05-02T14:36:01.480572 #11928:590790]  INFO -- : <AEMethod dump_root>   Attribute - miq_server_id: 1
[----] I, [2018-05-02T14:36:01.481441 #11928:590790]  INFO -- : <AEMethod dump_root>   Attribute - object_name: Request
[----] I, [2018-05-02T14:36:01.482306 #11928:590790]  INFO -- : <AEMethod dump_root>   Attribute - request: dump_root
[----] I, [2018-05-02T14:36:01.483857 #11928:590790]  INFO -- : <AEMethod dump_root>   Attribute - service: #<MiqAeMethodService::MiqAeServiceServiceAnsiblePlaybook:0x0000000012fed7f8>
[----] I, [2018-05-02T14:36:01.484733 #11928:590790]  INFO -- : <AEMethod dump_root>   Attribute - service_id: 4
[----] I, [2018-05-02T14:36:01.486200 #11928:590790]  INFO -- : <AEMethod dump_root>   Attribute - tenant: #<MiqAeMethodService::MiqAeServiceTenant:0x0000000012ffd900>
[----] I, [2018-05-02T14:36:01.487648 #11928:590790]  INFO -- : <AEMethod dump_root>   Attribute - user: #<MiqAeMethodService::MiqAeServiceUser:0x0000000012ffdd88>

Setting to ON_QA for validation.

Comment 16 Shveta 2018-05-04 02:41:29 UTC
Verification blocked by this issue

Comment 17 Tina Fitzgerald 2018-05-07 21:06:41 UTC
Confirmed that verification is blocked as stated in comment 16.

Comment 18 Chris Pelland 2018-05-23 21:04:57 UTC

The BZ that was blocking verification of this BZ has now been fixed and included in the latest 5.9.3 build:


Comment 19 drew uhlmann 2018-05-24 18:04:25 UTC
Created attachment 1441176 [details]
SUI log run screenshot

Comment 20 drew uhlmann 2018-05-24 18:04:50 UTC
Created attachment 1441177 [details]
CUI run screenshot

Comment 21 drew uhlmann 2018-05-24 18:18:56 UTC
Created attachment 1441180 [details]
the right screenshot :{

Comment 22 drew uhlmann 2018-05-24 18:19:35 UTC
See only the last screenshot please. Looks to be working to me.

Comment 23 drew uhlmann 2018-05-24 18:23:44 UTC
Q-task_id([resource_action_24]) in the screenshot is what shows that that run was from the SUI. The other run at the top is a CUI run.

Comment 24 Shveta 2018-05-24 18:29:17 UTC
Fixed in

Comment 25 Tina Fitzgerald 2018-05-30 14:22:37 UTC
*** Bug 1583782 has been marked as a duplicate of this bug. ***

Comment 26 Tsai Li Ming 2018-05-31 15:45:38 UTC
I tested in

In SSUI, it returns differntly

[----] I, [2018-05-31T11:44:40.413414 #12647:1255a48]  INFO -- : Instantiating [/Integration/AWS/Methods/Get_Bucket_Name?MiqServer%3A%3Amiq_server=1000000000001&ServiceTemplate%3A%3Aservice_template=1000000000001&User%3A%3Auser=1000000000001&object_name=Get_Bucket_Name&vmdb_object_type=service_template]

[----] I, [2018-05-31T11:44:49.930662 #12647:1255444]  INFO -- : Instantiating [/Integration/AWS/Methods/Get_Bucket_Name?MiqServer%3A%3Amiq_server=1000000000001&Service%3A%3Aservice=1000000000001&User%3A%3Auser=1000000000001&dialog_param_obj_name=0&object_name=Get_Bucket_Name&vmdb_object_type=service]

 Attribute - vmdb_object_type: service <== Hit the refresh button next to the field
 Attribute - vmdb_object_type: service_template <== First load

Comment 27 Tsai Li Ming 2018-05-31 15:47:01 UTC
(In reply to Tsai Li Ming from comment #26)

In the OPS UI, it is consistent

Comment 28 Tsai Li Ming 2018-05-31 16:59:02 UTC
With https://bugzilla.redhat.com/show_bug.cgi?id=1574774 ,

I can't use a different dialog form attached to the button, compared to the initial form that was created as part of the service catalog.

The API,, will return HTTP 500. 

The dialog_id will not match.

Comment 29 drew uhlmann 2018-05-31 17:16:32 UTC
If this ticket got verified, I'm not sure why it got reopened as NEW. It's expected behavior that the logs from the SUI and the CUI are different. I have no idea why that behavior would be considered a bug. I think this should be closed as verified, and if comment 28 actually is a bug, that it should be on a new ticket.

Comment 30 Tsai Li Ming 2018-05-31 17:29:22 UTC
Based on Comment #3 and Comment #4, Jeff was using the Refresh button. This was fixed but not when the form was first loaded when the user clicks on the button that is attached to the Service object.

See Comment #26 for the difference.

Comment 31 Tsai Li Ming 2018-05-31 17:30:01 UTC
Created attachment 1446400 [details]
Edit button on Service object

Comment 32 Tsai Li Ming 2018-05-31 17:31:42 UTC
Created attachment 1446401 [details]
Logs from going into the dialog form and clicking refresh button

Comment 33 drew uhlmann 2018-05-31 17:48:04 UTC
I do still believe that if this bug failed QE that rather than going straight to new it should have been listed as failed QE.

Comment 34 Tsai Li Ming 2018-05-31 17:55:52 UTC
Sure. Can you help move it to Failed QE? I don't see such a status available.

Comment 35 Shveta 2018-05-31 20:39:21 UTC
Okay so the BZ does not mention anything about refresh button .
SO the verification was based on a dialog with custom button and not with refresh button. 

Talked to Drew and the fix for refresh button will also be done as part of this BZ itself. 
So Changing the status to Assigned state.

Comment 36 drew uhlmann 2018-05-31 21:14:38 UTC
I think the ticket originally was about the refresh button, that just wasn't super-clear. I also wonder if the https://github.com/ManageIQ/manageiq-ui-service/blob/master/client/app/states/catalogs/details/details.state.js#L137 target type is supposed to just be the service? But currently testing that is blocked by an issue where I can't load the service catalog at all due to this: https://github.com/ManageIQ/manageiq-api/issues/388.

Comment 39 drew uhlmann 2018-06-04 19:09:52 UTC
Just for clarity, the refresh button is the key to this dialog setup, yes? Your reproduction steps didn't actually include the fact that this is a refresh button issue. It would be imperative to have dialog exports attached to these tickets, it makes reproducing issues much simpler when we have copies of the dialogs themselves and not just screenshots.

Comment 41 Tina Fitzgerald 2018-06-11 21:45:22 UTC
The reported issue is that the OPS UI and SUI are not consistent in the root object containing the Service object. Comment 15 states the Service object is included in the root object for the OPS UI and SUI.

The reproducing steps in comment 10 do not mention refresh. This issue has been resolved for the initially reported issue.
If there are other issues, including refresh, a new ticket should be opened to track the issue.

Setting status back to verified as stated in comment 24.

Comment 43 errata-xmlrpc 2018-07-12 13:14:16 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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