Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: It seems that when the service provisioning profile is executed, the wrong group is being substituted into /System/Policy/ServiceTemplateProvisionRequest_created where /${/#miq_request.resource.ci_type}/Provisioning/Profile/${/#user.normalized_ldap_group}#get_auto_approval_state_machine is called in rel5. It looks to me like the user from a separate task being run (which is a totally unrelated looping state machine) is bleeding into the new task being ordered. I am seeing the user for the unrelated task in $evm.root['user'] in a method called right before calling ServiceTemplateProvisionRequest_created. Version-Release number of selected component (if applicable): cfme-5.9.4.7-1 How reproducible: 1. Have a unrelated state machine owned by a different user running in a retry state running. 2. Provision a new unrelated service (different user from running state machine). 3. Look at the values in $evm.root['user'] with a method on meth4 in of /System/Policy/ServiceTemplateProvisionRequest_created. Actual results: $evm.root['user'] has the contents of the user from the unrelated state machine. Expected results: $evm.root['user'] should have the contents of the current new request being ordered. Additional info:
Hi Patrick, Can you provide the evm.log and automation.log showing the incorrect user? Please supply the service request ID as well. Thanks, Tina
Logs sent via email.
Please provide detailed steps to recreate the issue.
Hi I thought the original post was pretty clear: 1. Have a unrelated state machine owned by a different user running in a retry state running. 2. Provision a new unrelated service (different user from running state machine). 3. Look at the values in $evm.root['user'] with a method on meth4 in of /System/Policy/ServiceTemplateProvisionRequest_created. Please let me know what more you need.
The steps to re-create the issue should list all the steps that the customer executes to hit into the issue. The format would be more like: 1. Go to place A, click on button Task_A, set value as xxx. 2. Go to place B, click on button Task_B, set value as xxx. 3. Go to place C, click on button Task_c. ... I consider myself not new to automate. But I have no idea how to implement the steps you provided above. And I'm sure later QE would run into the same situation. Thanks.
Don't know how to re-create the issue.
Created attachment 1522229 [details] sample domain I am attaching a sample domain. You will have to: 1) Create two users in two different groups one group should be called require-approval-group. Remember to make only one of the users a member of this group. The other group can be something like non-approval-group. 3) Import and enable this domain 4) create a catalog item of type generic that points to /provtest/statemachine/mystatemachine 5) Monitor the automation.log 6) First order the catalog item as the user who is NOT in require-approval-group. Wait a few mins for it to start looping in the log. 7) Then order the catalog item as the user who IS in require-approval-group You will notice that when the second user orders the catalog item, its group is not require-approval-group but it is non-approval-group which is the group the first user is a member of.
Thanks for the instructions. Looking into it.
Followed the steps in Comment #8 and reproduced the issue. After step 7 where user B in require-approval-group logged in, User.current_user did not return back user B but returned user A from step 6. In other words, somehow User.current_user did not return back the currently logged in user. Forward the BZ to UI team for troubleshooting. My test appliance: 10.8.99.175.
This is a duplicate of https://bugzilla.redhat.com/show_bug.cgi?id=1671563 Lucy was able to reproduce the issue on the provided appliance. After applying the patch from the other BZ, the problem was resolved. That patch is being applied to 5.9 and 5.10, so the fix will show up in your desired time frame. Marking this as a duplicate so it will be easier for you to see the exact versions this was fixed. Thanks, Keenan *** This bug has been marked as a duplicate of bug 1671563 ***