Created attachment 1655171 [details] screen shot of catalog with multi select field Description of problem: ----------------------- I created a service catalog based on a Tower job template that uses a survey so that extra variables could be passed to Tower from CFME. The survey has a multiple select Answer type field. A service dialog created(on CFME) from this Ansible job template also has a multi select field, like expected. However, the extra variables provided in the service dialog while ordering the catalog are not being passed to Tower from CFME. See attached screen shot that shows a screen shot of the catalog with the multi select Survey field. Snippet from evm.log shows this : "Array::dialog_param_Department"=>"," [----] I, [2020-01-23T16:06:15.792850 #36458:2b22cd5f05bc] INFO -- : Q-task_id([r13_service_template_provision_request_13]) MIQ(MiqQueue.put) Message id: [82929], id: [], Zone: [default], Role: [automate], Ser ver: [], MiqTask id: [], Ident: [generic], Target id: [], Instance id: [], Task id: [], Command: [MiqAeEngine.deliver], Timeout: [600], Priority: [100], State: [ready], Deliver On: [], Data: [], Args: [{:object_ type=>"ServiceTemplateProvisionTask", :object_id=>12, :namespace=>"AutomationManagement/AnsibleTower/Service/Provisioning/StateMachines", :class_name=>"Provision", :instance_name=>"CatalogItemInitialization", :a utomate_message=>"create", :attrs=>{"dialog_service_name"=>"kGx840Kqqe", "dialog_limit"=>"", "Array::dialog_param_Department"=>",", "request"=>"clone_to_service", :service_action=>"Provision", "Service::Service" =>1}, :user_id=>1, :miq_group_id=>2, :tenant_id=>1}] Version-Release number of selected component (if applicable): ------------------------------------------------------------- 5.11 How reproducible: ----------------- Always Steps to Reproduce: ------------------- 1.Create a service catalog based on a Tower job template that uses a survey so that extra variables could be passed to Tower from CFME. 2.Order the catalog. Actual results: --------------- Extra variables provided in a service dialog while ordering a service catalog are not being passed to Tower from CFME. Expected results: ----------------- Extra variables provided in a service dialog while ordering a service catalog should be passed to Tower from CFME. Additional info: ----------------
See https://bugzilla.redhat.com/show_bug.cgi?id=1761581
Hey Nandini, ordering any service on that appliance gets a Data {"error":{"kind":"internal_server_error","message":"undefined method `manager' for nil:NilClass","klass":"NoMethodError"}} error. That's not related, right?
If the error in comment 4 is what's breaking this, it would be better to have that in the description of the ticket to make this clearer.
As well as the trace: [----] I, [2020-01-27T14:05:24.708178 #3429:2ab9d5c2c874] INFO -- : MIQ(Api::ServiceCatalogsController.log_request) Parameters: {"action"=>"update", "controller"=>"api/service_catalogs", "format"=>"json", "body"=>{"service_name"=>"Drew_5_11_1_2_3", "limit"=>"asfasdf", "param_Department"=>[nil, nil], "action"=>"order"}} [----] E, [2020-01-27T14:05:24.760957 #3429:2ab9d5c2c874] ERROR -- : MIQ(Api::ServiceCatalogsController.api_error) NoMethodError: undefined method `manager' for nil:NilClass [----] E, [2020-01-27T14:05:24.761137 #3429:2ab9d5c2c874] ERROR -- : MIQ(Api::ServiceCatalogsController.api_error) /var/www/miq/vmdb/app/models/service_template_ansible_tower.rb:59:in `my_zone' /var/www/miq/vmdb/app/models/service_template_provision_request.rb:46:in `my_zone' /var/www/miq/vmdb/app/models/miq_request.rb:202:in `call_automate_event_queue' /var/www/miq/vmdb/app/models/service_order.rb:64:in `block in process_checkout' /opt/rh/cfme-gemset/gems/activerecord-5.1.7/lib/active_record/relation/delegation.rb:39:in `each' /opt/rh/cfme-gemset/gems/activerecord-5.1.7/lib/active_record/relation/delegation.rb:39:in `each' /var/www/miq/vmdb/app/models/service_order.rb:62:in `process_checkout' /var/www/miq/vmdb/app/models/service_order.rb:56:in `checkout_immediately' /var/www/miq/vmdb/app/models/service_order.rb:96:in `order_immediately' /var/www/miq/vmdb/app/models/service_template_provision_request.rb:35:in `process_service_order' /opt/rh/cfme-gemset/gems/activesupport-5.1.7/lib/active_support/callbacks.rb:413:in `block in make_lambda' /opt/rh/cfme-gemset/gems/activesupport-5.1.7/lib/active_support/callbacks.rb:235:in `block in halting_and_conditional' /opt/rh/cfme-gemset/gems/activesupport-5.1.7/lib/active_support/callbacks.rb:511:in `block in invoke_after' /opt/rh/cfme-gemset/gems/activesupport-5.1.7/lib/active_support/callbacks.rb:511:in `each' /opt/rh/cfme-gemset/gems/activesupport-5.1.7/lib/active_support/callbacks.rb:511:in `invoke_after' /opt/rh/cfme-gemset/gems/activesupport-5.1.7/lib/active_support/callbacks.rb:132:in `run_callbacks' /opt/rh/cfme-gemset/gems/activesupport-5.1.7/lib/active_support/callbacks.rb:827:in `_run_create_callbacks' /opt/rh/cfme-gemset/gems/activerecord-5.1.7/lib/active_record/callbacks.rb:344:in `_create_record' /opt/rh/cfme-gemset/gems/activerecord-5.1.7/lib/active_record/timestamp.rb:102:in `_create_record'
So comments four, five, and six are unrelated to the issue. I added tower as a provider on the appliance and created a new catalog item that is of type tower (since this won't work without it). But I do think the UI team should look at this first since the API isn't getting any value passed in from the UI for the multiselect dropdown in question. The first dropdown has default values set (which show up incorrectly to start with on the dialog editor preview screen) but also don't load on service order.
I'm also noticing an interesting thing where if you load the dialog on the service order screen and pick engineering first it picks a different value instead which feels like a separate UI issue.
Nope, I lied. Something about that field on the dialog is wonky which was causing what I saw in 8 and 7. Take three...
If multiselect fields don't have types, the UI will break, as per the comments I wrote in this ticket. The API also will not have the correct values, also as described above in this ticket. I think we've fixed the issue of dialog fields of this sort not having types on latest and I don't think this is actually reproduceable unless you import an old dialog that has a blank type. The first symptom of this is the UI not showing default values correctly.
If we wanted to fix this, I think that the "bug" here is that the UI shows "Nothing selected" for this multiselect when it should be showing the default value. The backend seems to be working correctly and the "Nothing selected" I think is added somewhere in the ui-components repo and it must be doing some kind of check on the type of the field.
After a conversation with Billy and Tina, here's the final (I promise) consensus: We have more granularity on certain field type options than the Tower dialog options seem to have which means that when we create service dialogs this way we cannot set some of the fields because we don't know what they should be set to and CF will set them to nil. For example, all multiselect dropdowns will have on the CF side either Int or String types, but Tower doesn't explicitly differentiate as a dialog field option so they will all be set to nil. This will break any service ordered with the newly created dialog unless the user knows to go back into the created dialog and fix that option in the dialog editor. There are also some boolean options that get set to nil, neither true nor false, and the reconfigurable option on the field seems to always be set to true. Some of these could be fixed by us by changing the options the UI is using (https://github.com/ManageIQ/manageiq-ui-classic/commit/fff01a7b8537d4bc5ec125189459bba04bedf799#diff-3665c93a6fe75e5c0bf20810423d4fdbR83) to create the fields to be correct but a few of them feel like only things the user would know and not things we should try to guess at. It feels like we need a KB article and documentation to instruct people that when they create dialogs this way, they will have to go back in and manually edit the fields to make sure they're correct. We also don't have a reliable way of differentiating dialogs created this way from ones that were created from the UI. Unfortunately, using a dialog that has been created like this, even one that's invalid, doesn't reliably error in any way that we can point people to so this might be difficult to catch. Here are some symptoms: Before service order: Service Order: the field defaults set might be replaced by "Nothing selected" before you submit the dialog and the dropdown, when you pick the first option, might load the last instead. You also might see a dearth of UI errors about required fields. After service order: The UI will not show any options passed in dropdowns. This doesn't feel like something we can validate or fix in a way that's not going to break a bunch of everything else and make anyone happy.
Drew, I'm wondering why this BZ is in POST state. Was anything fixed at all ? If so, could you share the GH link ?
Sorry, I forgot that I'd only discussed it on that call: https://github.com/ManageIQ/manageiq/pull/19780