Red Hat Bugzilla – Bug 1565845
Service buttons do not attach $evm.root['service']
Last modified: 2018-07-12 09:14:53 EDT
Per summary, a button attached to a service does not attach to $evm.root['service'] in automate, as it does for the classic UI.
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