Description of problem: refresh methods stop being called after working for several days Version-Release number of selected component (if applicable): 5.9.2.4-3 How reproducible: random times Steps to Reproduce: 1.start dialog 2.make a selection that is supposed to cause a field to be refreshed Actual results: no automation is called at all Expected results: the automation is called as usual Additional info: we haven't been able to identify why dialogs that were working fine break. copying the dialog to a new one fixes it, but then it breaks later at a random time.
Hi Felix, My understanding is that the customer has dialogs that work for some period of time, then stop working without any changes to the environment. At that point, copying the dialog to a new dialog will result in the correct behavior. Could you ask the customer to send us an example of a "broken" dialog and the copied version that works properly? Could you also ask them to supply the Automate domain(s) needed for the dialog? Let me know if you have any questions. Thanks, Tina
Hi Felix, Could you ask the customer to first try restarting the UI appliance when the dialog stops working to see if that resolves the issue? Thanks, Tina
(In reply to Tina Fitzgerald from comment #6) > Hi Felix, > > Could you ask the customer to first try restarting the UI appliance when the > dialog stops working to see if that resolves the issue? > > Thanks, > Tina they do that as part of their workarounds. I didn't mention it because I didn't think it really had an impact at all. the workaround of cloning the dialog stopped working today for one dialog. as a note, this only happens in the self service version of the dialog, not the classic ui version.
Hi Felix, Thanks for the update. When the customer restarted the UI appliance, did the problem go away? I'm going to check out the new information/logs. A customer call sounds like a good idea, but Erik and I discussed giving the customer some debugging instructions that will give us a better idea of the exact issue. I hope to have specifics shortly. What time(s) would the customer be available today? Thanks, Tina
the customer us not available today but is available monday. the customer has tried restarting the appliance to no avail. he loads the dialogs and tails the automation logs at the same time - but the automation isn't at all triggered and no automation call is logged when that happens. I think a remote session would be best to investigate.
Are there any javascript errors that are happening? To check, if the customer is using chrome, they can open the developer tools by going to the "..." menu in the upper right, then going to "More tools" and then "Developer tools" before loading the dialog. There should be a console output and when they click around in the dialog, if a javascript error happens, it should be noticeable. If there is no console output, ensure that the "console" tab is selected before loading the dialog and then retry. If the customer is using firefox, they can simply hit F12 to open the developer tools, or they can go to the similar "..." menu and click "developer" and then "toggle tools". However, by default, I don't think Firefox shows the console, so they will then need to click on the little console icon, which is third from the left in the row of icons at the top.
Hi Shveta, Could you setup a reproducer environment? Thanks, Tina
Hi Felix, I reviewed the recorded session and have a few questions. The customer showed us 2 different environments: cf.cdvu.es.onpremise <----- Everything worked properly here cf.es.onpremise <----- Service UI, Dialog issue reproduced here(7:22 in recording) Linux RHEL con PHP <----- Service Dialog issue Can you ask the customer: 1. Take a screen shot of the "About" version on both appliances. 2. Provide a hot fix version from both appliances (rpm -q cfme-gemset) 3. Supply Service dialogs for Linux RHEL con PHP, from both appliances. Thanks, Tina
Hi Felix, Thanks for the update. We haven't been able to reproduce the customer issue. Could you ask the customer to supply the database from the cf.es.onpremise environment? Thanks, Tina
Hi Ania, We were able to reproduce the issue using the database provided by the customer. We found the issue and are working on a fix. It's a small change, and we expect to have a PR ready later today. Regards, Tina
https://github.com/ManageIQ/manageiq-ui-service/pull/1454
New commit detected on ManageIQ/manageiq-ui-service/master: https://github.com/ManageIQ/manageiq-ui-self_service/commit/119bd0fd4bf8ecd56470b3a3f932a77e2a78bc9c commit 119bd0fd4bf8ecd56470b3a3f932a77e2a78bc9c Author: Erik Clarizio <eclarizi> AuthorDate: Thu Jul 12 12:57:01 2018 -0400 Commit: Erik Clarizio <eclarizi> CommitDate: Thu Jul 12 12:57:01 2018 -0400 Ensure the provision resource action id is used Fixes https://bugzilla.redhat.com/show_bug.cgi?id=1598475 client/app/states/catalogs/details/details.state.js | 5 +- client/app/states/catalogs/details/details.state.spec.js | 58 +- 2 files changed, 43 insertions(+), 20 deletions(-)
Hi Tina , I am not able to verify this BZ on 5.10 . After restoring db and restarting EVM server , the server never starts and I can't login . Please check appliance 10.8.59.85. I also have a new appliance : 10.8.197.235. where I have copied the db but not restored as I can't restart the server once shut down. Thanks, Shveta
Hi Shveta, Erik is going to look into this. Thanks, Tina
I went in and manually created a test dialog/test catalog item. The reason this bug exists is because when a service template has both a 'Provision' resource action and a 'Retirement' resource action, if the 'Retirement' resource action is for some reason first in the database, it was not using the right resource action ID. So, I've manually changed the "Test" service catalog to emulate what the customer's database was meant to show. irb(main):009:0> ServiceTemplate.last.resource_actions => #<ActiveRecord::Associations::CollectionProxy [#<ResourceAction id: 25, action: "Provision", dialog_id: 2, resource_id: 1, resource_type: "ServiceTemplate", created_at: "2018-08-23 22:20:15", updated_at: "2018-08-23 22:20:15", ae_namespace: "Service/Provisioning/StateMachines", ae_class: "ServiceProvision_Template", ae_instance: "CatalogItemInitialization", ae_message: nil, ae_attributes: {:service_action=>"Provision"}, configuration_template_id: nil, configuration_template_type: nil>, #<ResourceAction id: 26, action: "Retirement", dialog_id: 2, resource_id: 1, resource_type: "ServiceTemplate", created_at: "2018-08-23 22:20:15", updated_at: "2018-08-23 22:20:15", ae_namespace: "Service/Retirement/StateMachines", ae_class: "ServiceRetirement", ae_instance: "Default", ae_message: nil, ae_attributes: {:service_action=>"Retirement"}, configuration_template_id: nil, configuration_template_type: nil>]> I realize this might be hard to follow, but the important bit is that "Provision" is first, and "Retirement" is second. This is the correct scenario and will work even without the fix to this bug. I needed to change this, so I simply updated the ID on the "Provision" dialog to be 27 instead of 25: irb(main):014:0> ResourceAction.where(id: 25).update_all(id: 27) irb(main):016:0> ServiceTemplate.last.resource_actions.first => #<ResourceAction id: 26, action: "Retirement", dialog_id: 2, resource_id: 1, resource_type: "ServiceTemplate", created_at: "2018-08-23 22:20:15", updated_at: "2018-08-23 22:20:15", ae_namespace: "Service/Retirement/StateMachines", ae_class: "ServiceRetirement", ae_instance: "Default", ae_message: nil, ae_attributes: {:service_action=>"Retirement"}, configuration_template_id: nil, configuration_template_type: nil> irb(main):017:0> ServiceTemplate.last.resource_actions.second => #<ResourceAction id: 27, action: "Provision", dialog_id: 2, resource_id: 1, resource_type: "ServiceTemplate", created_at: "2018-08-23 22:20:15", updated_at: "2018-08-23 22:20:15", ae_namespace: "Service/Provisioning/StateMachines", ae_class: "ServiceProvision_Template", ae_instance: "CatalogItemInitialization", ae_message: nil, ae_attributes: {:service_action=>"Provision"}, configuration_template_id: nil, configuration_template_type: nil> Now, you can go into the service UI, and verify that a) it doesn't blow up, and b) if you look at the request made in the developer tools when clicking on the check box I set up, it correctly sends the resource_action_id of '27'. Let me know if you need any other assistance with this, I realize we're not actually using the customer's data here, but I tried to mimic the root cause of the problem with regards to how the backend resource_actions were set up.
Hi Shveta, I'm confident this issue has been resolved based on Erik's comments above. Let me know if you have any questions or concerns. Thanks, Tina
Checked the dialog mentioned above , dialog doesn't blow up and API log shows ============ [----] I, [2018-08-24T10:44:40.205259 #12140:17351bc] INFO -- : MIQ(Api::ServiceDialogsController.log_request) Parameters: {"action"=>"update", "controller"=>"api/service_dialogs", "format"=>"json", "body"=>{"action"=>"refresh_dialog_fields", "resource"=>{"dialog_fields"=>{"check_box_1"=>"t", "text_box_1"=>"Box is not checked"}, "fields"=>["text_box_1"], "resource_action_id"=>"27", "target_id"=>"1", "target_type"=>"service_template"}}} Verifying based on above comments and testing.