Refresh button on dynamic Text Area Box breaks service provisioning dialog element

Solution Unverified - Updated -

Environment

Red Hat CloudForms 4.7/CFME 5.10.x

Affected CFME Version-Release numbers: CFME 5.10.3 and CFME 5.10.4

Issue

When clicking the refresh button on a dynamic dialog, the value appears to load fine in the UI, however the value is never accepted, and is showing as nil in the dialog_parser method:

  • Below, there are 2 dynamic dialogs, both with the exact same setup and automate method populating the values. "dialog_dummy_text_box_1" was refreshed, and shows the value nil, while "dialog_dummy_text_box_2" was not refreshed, and shows the "No worries Mate!" value. Note, these 2 dialogs have "Load on Init" enabled.
[----] I, [2019-06-06T10:36:37.149619 #20839:d1f128]  INFO -- : Q-task_id([r1000000000010_service_template_provision_task_1000000000010])  dialog_options: {"dialog_dummy_text_box_1"=>nil, "dialog_dummy_text_box_2"=>"No worries Mate!", "request"=>"clone_to_service", :service_action=>"Provision", "Service::Service"=>1000000000010}
  • When trying it with "Load on Init" disabled, we still see the refresh is sending a nil value for "dialog_dummy_text_box_1" as shown below:
[----] I, [2019-06-06T10:39:53.889073 #20847:640ea9c]  INFO -- : Q-task_id([r1000000000011_service_template_provision_task_1000000000011])  dialog_options: {"dialog_dummy_text_box_1"=>nil, "dialog_dummy_text_box_2"=>"", "request"=>"clone_to_service", :service_action=>"Provision", "Service::Service"=>1000000000011}

Resolution

Updating/Upgrading your CFME appliances to 5.10.5 should resolve this issue.

Root Cause

This is caused as a result of a bug Bug 1717971

Diagnostic Steps

Steps to reproduce:

  • Create a Automation method to populate the the dynamic Text Area Box dialog field:
$evm.log(:info, "dialog_dummy1 is #{$evm.object['dialog_dummy1']}")
$evm.log(:info, "dialog_dummy2 is #{$evm.object['dialog_dummy2']}")
$evm.log(:info, "dialog_dummy3 is #{$evm.object['dialog_dummy3']}")
list_values = {
     'required'   => true,
     'value'     => "No worries Mate!"
  }
list_values.each { |key, value| $evm.object[key] = value }
exit MIQ_OK
  • Create a service provisioning dialog with a dynamic Text Area Box (here we created three called dummy1, dummy2, and dummy3) linked to the method.
  • Create a generic service catalog item using the default entry point and configure to use the dialog created above.
  • Use of the dialog and the refresh button causes submission to fail because the parameter gets destroyed or set to nil or something, and is not submitted with the request.
  • Push refresh on the first element, then submit: the request fails with the error, because only dialog variables dummy2 and dummy3 are being passed in the body, and all three are configured to be required:
[----] I, [2019-05-31T15:24:06.173426 #7633:3c4a9c0]  INFO -- : MIQ(Api::ServiceCatalogsController.log_request) Parameters:     {"action"=>"update", "controller"=>"api/service_catalogs", "format"=>"json", "body"=>{"dummy2"=>"No worries Mate!", "dummy3"=>"No worries Mate!", "action"=>"order"}}
[----] E, [2019-05-31T15:24:06.276278 #7633:3c4a9c0] ERROR -- : MIQ(Api::ServiceCatalogsController.api_error) API Error
[----] E, [2019-05-31T15:24:06.276503 #7633:3c4a9c0] ERROR -- : MIQ(Api::ServiceCatalogsController.api_error) Api::BadRequestError: Failed to order Service Template id:71 name:'bug' - New tab/New section/Dummy 1 is required
  • If the second refresh button is pushed, the same behavior occurs, and the second parameter, dummy2, is not sent in the submit request.

This solution is part of Red Hat’s fast-track publication program, providing a huge library of solutions that Red Hat engineers have created while supporting our customers. To give you the knowledge you need the instant it becomes available, these articles may be presented in a raw and unedited form.

Comments