Description of problem: When a user that resides in a child tenant submits a create_provision_request from a generic service catalog item they cannot see the miq_provision_request in the Services / Requests page because the miq_provision_request for some reason is being assigned to the wrong tenant. This is currently affecting anyone using "build_request" in a CF multi-tenancy environment. Version-Release number of selected component (if applicable): 5.5.2.4 How reproducible: 100% Steps to Reproduce: 1. Create a child tenant 2. Create a group with self-service role and child tenant 3. Create a user associated to group 4. Create a service catalog item that runs create_provision_request I.e. args = ["1.1", {"guid"=>"043b2e64-eb15-11e5-b658-5254001018da", "name"=>"cirros"}, {"customization_template_id"=>"7", "security_groups"=>"44", "number_of_vms"=>"1", "cloud_tenant"=>"1", "vm_name"=>"changeme", "guest_access_key_pair"=>"39", "cloud_network"=>"14", "instance_type"=>"56", "number_of_sockets"=>"1", "cores_per_socket"=>"1", "vm_memory"=>"512", "retirement"=>"604800", "retirement_warn"=>"259200"}, {"user_name"=>"clouduser1", "owner_first_name"=>"cloud", "owner_last_name"=>"user1", "owner_email"=>"clouduser1.com"}, {"environment"=>"dev", "cloud_tenant"=>"project1", "flavor"=>"m1.tiny", "prov_scope"=>"tenant1"}, {"provider_id"=>"6", "flavor"=>"m1.tiny", "group_id"=>"19", "group_name"=>"group_tenant1", "cloud_tenant_id"=>"1", "guest_access_key_pair_name"=>"test-key", "cloud_network_name"=>"project1-private", "service_id"=>"55", "service_guid"=>"0a8f3a14-f5cc-11e5-b2d3-5254001018da", "environment"=>"dev", "cloud_tenant"=>"project1", "prov_scope"=>"tenant1"}, nil, nil] request = $evm.execute('create_provision_request', *args) 5. You will see the service_template_provision_request is owned by the correct user and group and tenant. Yeah! 6. However after create_provision_request runs it creates a miq_provision_request and in the pg database it shows the correct user, group and the tenant id from the parent tenant. 7. What does this mean? If means that users living in sub-tenants cannot see their requests in the Services / Requests queue. Actual results: Users cannot see their miq_provision_requests Expected results: Users should see their miq_provision_requests Additional info:
Tina - Will need to work with Madhu on this one. Would be good to get an environment setup to reproduce.
https://github.com/ManageIQ/manageiq/pull/11435
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/159a98bd7b0dcb84439fc315af254fa797616b8d commit 159a98bd7b0dcb84439fc315af254fa797616b8d Author: Madhu Kanoor <mkanoor> AuthorDate: Wed Sep 21 17:04:03 2016 -0400 Commit: Madhu Kanoor <mkanoor> CommitDate: Tue Sep 27 11:23:03 2016 -0400 Set the User.current_user in Automation Engine https://bugzilla.redhat.com/show_bug.cgi?id=1322983 lib/miq_automation_engine/engine/miq_ae_service.rb | 3 +++ lib/miq_automation_engine/engine/miq_ae_workspace.rb | 1 + .../engine/miq_ae_workspace_runtime_spec.rb | 14 ++++++++++++++ 3 files changed, 18 insertions(+) create mode 100644 spec/lib/miq_automation_engine/engine/miq_ae_workspace_runtime_spec.rb