Bug 1565845

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

Created attachment 1420469 [details]
From classic UI

Created attachment 1420470 [details]
From self service UI

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.

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?

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

This works properly in the 5.9.2.4.20180501195858_35dc609 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.

Verification blocked by this issue
https://bugzilla.redhat.com/show_bug.cgi?id=1574774

Confirmed that verification is blocked as stated in comment 16.

Shveta,

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

https://bugzilla.redhat.com/show_bug.cgi?id=1578990

Created attachment 1441176 [details]
SUI log run screenshot

Created attachment 1441177 [details]
CUI run screenshot

Created attachment 1441180 [details]
the right screenshot :{

See only the last screenshot please. Looks to be working to me.

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.

Fixed in 5.9.3.0.20180522175053_3940873

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

I tested in 5.9.3.0.20180522175053_3940873

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

(In reply to Tsai Li Ming from comment #26)

In the OPS UI, it is consistent

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, 
https://192.168.0.169/api/services/1000000000016/service_dialogs/XXX?expand=resources&attributes=content, will return HTTP 500. 

The dialog_id will not match.

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.

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.

Created attachment 1446400 [details]
Edit button on Service object

Created attachment 1446401 [details]
Logs from going into the dialog form and clicking refresh button

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.

Sure. Can you help move it to Failed QE? I don't see such a status available.

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.

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.

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.

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.

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.

https://access.redhat.com/errata/RHSA-2018:2184