Bug 1701098 - Users should not be able approve/deny their own provision/retirement requests
Summary: Users should not be able approve/deny their own provision/retirement requests
Keywords:
Status: CLOSED NOTABUG
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning
Version: 5.10.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: GA
: 5.10.6
Assignee: Tina Fitzgerald
QA Contact: Antonin Pagac
Red Hat CloudForms Documentation
URL:
Whiteboard:
Depends On:
Blocks: 1704905
TreeView+ depends on / blocked
 
Reported: 2019-04-18 05:11 UTC by Niladri Roy
Modified: 2019-11-06 20:00 UTC (History)
7 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-06-17 19:51:44 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)

Description Niladri Roy 2019-04-18 05:11:31 UTC
Description of problem:
Users can be given the permission of "Approve and Deny" under Everything > Services > Requests > Operate > Approve and Deny

But this permissions allows users to approve their own provisioning requests.
Also the service retirements get auto-approved and retirement starts

This is not a desired behaviour as user should not be able to approve/deny their own provision/retirement requests.

Version-Release number of selected component (if applicable):
5.10.0.33

How reproducible:
Always

Steps to Reproduce:
A. Create a new custom role

   1. I've changed the approval behaviour to manual by setting approval_type to manual 
      in Service > Provisioning> StateMachines> ServiceProvisionRequestApproval> Default
   2. copied EVMRole-user_self_service to niroy-role
      "Access Restriction for Services, VMs, and Templates" was set to "None"
   3. created a service which provisions a VM on Vmware as the "admin" user
   4. logged in to self_service portal as "niroy" user with the niroy-role assigned to its group


B. With the "Approve and Deny" Role off

   From Admin UI   
   -------------
   User provisions, request lands up in approval queue, user doesn't see the option of approve
   Same behaviour with retirement

   From Service UI
   ----------------
   User provisions, request is queued for approval
   User sees the error "There was an error removing one or more services" when he tries to retire service

C. With the "Approve and Deny" Role on

   From Admin UI   
   -------------
   User provisions, request lands up in approval queue, user sees only the "approve" button for his own request. There is no deny/reject button
   Same behaviour with retirement

   From Service UI
   ----------------
   User provisions, request is queued for approval, user can approve his request from the admin UI. He only sees the approve button
   User retires the service, it gets auto-approved and the retirement starts.

Actual results:


Expected results:

With the Approve and Deny Role On:
1. Users should not be able to approve provision requests
2. Users should not be able to approve retirement requests
3. Users should be able to use the self-service portal for provisioning and retirement purposes


Additional info:
Approval and denial is handled by a separate team for my Cu

Comment 3 Tina Fitzgerald 2019-04-18 19:55:52 UTC
Everything looks reasonable with the exception of: The Service UI, With the "Approve and Deny" Role off.

The retire button should be disabled if the request will not be allowed.

Comment 4 Tina Fitzgerald 2019-04-18 20:16:07 UTC
Users should be able to approve provision/retirement requests as long as the role permits it.

Comment 5 Tina Fitzgerald 2019-04-18 20:21:12 UTC
Hi Loic,

Can you add your thoughts here on the expected behavior of the Service UI, regarding a users ability to approve their own provision/retirement requests?

Thanks,
Tina

Comment 6 Loic Avenel 2019-04-30 22:17:14 UTC
I think if the Role for Approve/Deny is not enable then User could not approve or deny a request in Classic UI or Service UI.

For SUI, the retirement button can be there but then the retirement Request goes in "pending Mode" until an admin with the right role can approve or deny.

Comment 8 Tina Fitzgerald 2019-06-10 13:51:45 UTC
Hi Loic,

In Comment 6 you stated:
"I think if the Role for Approve/Deny is not enable then User could not approve or deny a request in Classic UI or Service UI.

If the Role for Approve/Deny is enabled, should a user be able to approve or deny his/her own request?

Thanks,
Tina

Comment 9 Tina Fitzgerald 2019-06-10 14:11:43 UTC
There are 3 different issues/areas discussed in the problem description.

1. Should a user be able to approve/deny his/her own request?  I think the answer is based on the role(s). If the "Approve and Deny" role is enabled, the user should be able to approve/deny his own request, and should not be able to approve/deny his own request if the role is not enabled.

2. Missing Deny button. - The fact that the deny button is not present when the role is enabled feels like a separate bug, but that needs to be verified.

3. Retirement failing when the approve/deny role is not enabled.(Service UI)  There was a recent change to the retire API call that should resolve this issue. The retirement API was checking the approve/deny role. The code was changed to not check the approve/deny role since the retire role is responsible for that behavior.

Comment 10 Loic Avenel 2019-06-11 06:20:27 UTC
(In reply to Tina Fitzgerald from comment #8)
> Hi Loic,
> 
> In Comment 6 you stated:
> "I think if the Role for Approve/Deny is not enable then User could not
> approve or deny a request in Classic UI or Service UI.
> 
> If the Role for Approve/Deny is enabled, should a user be able to approve or
> deny his/her own request?
> 
> Thanks,
> Tina

So, we all agree if the Role is not enable then User cannot Approve/Deny is own request and an Approver has to do it for him.. 
But if it is enable, it seems weird the user has to go an approve his own request, it should be auto-approved...

Comment 12 Tina Fitzgerald 2019-06-17 19:51:44 UTC
Hi Loic,

The approval type is to set to auto for the OOTB Automate service provisioning auto approval state machine, so the request would be auto-approved unless/until the customer overrides it.

Let me know if you have any questions.

Thanks,
Tina


Note You need to log in before you can comment on or make changes to this bug.