Bug 1608554 - When a role has Operate on Service Requests, shows all requests in UI but not API
Summary: When a role has Operate on Service Requests, shows all requests in UI but not...
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: API
Version: 5.9.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: GA
: 5.10.0
Assignee: Keenan Brock
QA Contact: Antonin Pagac
: 1542810 (view as bug list)
Depends On:
Blocks: 1572700
TreeView+ depends on / blocked
Reported: 2018-07-25 19:27 UTC by David Luong
Modified: 2019-02-07 23:03 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-02-07 23:03:30 UTC
Category: Bug
Cloudforms Team: CFME Core
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Knowledge Base (Solution) 3544191 None None None 2018-07-25 20:10:54 UTC
Red Hat Product Errata RHSA-2019:0212 None None None 2019-02-07 23:03:37 UTC

Description David Luong 2018-07-25 19:27:29 UTC
Description of problem:
When a user has a role that has Services > My Services > Requests > Operate on it allows them to see all services in UI but only services they requested in the API.

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

How reproducible:

Steps to Reproduce:
1. Login with user with Services > My Services > Requests > Operate enabled
2. View Services > Requests
3. Query API on service_requests

Actual results:
UI will show all requests while API only shows requests requested by user

Expected results:
Parity between API and UI

Additional info:
Can reproduce locally

Comment 2 Joe Rafaniello 2018-07-26 17:13:33 UTC
Do you have an appliance with service requests and the custom role you created for this BZ?  I'm not sure how to setup my environment to recreate this.

Comment 5 Joe Rafaniello 2018-08-01 21:58:45 UTC
Hi David,

I'm still working on a fix for this using the appliance you sent me.  Please make sure it stays around for a few more days.

Thank you!

Comment 7 Joe Rafaniello 2018-08-07 14:21:41 UTC
David, I'm still working on this issue.  It turns out, we need to enhance our RBAC system to give the approver role "super administrator" level visibility to the request made in their tenant hierarchy (their tenant and descendent tenants).  The user interface implements something similar but the code can't be reused.  I will need to implement this in the backend, allow the API to use it, and eventually, migrate the UI code to use it also.

So, please keep the appliance up and running for the time being.  This is not a simple bug fix.  Technically, it's a new feature that appears to be a bug to the end user.

Comment 10 Keenan Brock 2018-08-09 20:22:09 UTC
What we've found today:

In G release, the api uses `is_admin?` to limit requests for other users.
The api uses feature identifier miq_request_approval
In H release, is_admin is switched over to using miq_request_superadmin.

What we are changing:

In H release, the API will be changed to use using miq_request_approval.

So for H release, both the API and the UI will use the miq_request_approval feature.
G release

Temporary fix:

In the G release, access the API with an administrator user to fetch all user's requests from the API.

Comment 11 Keenan Brock 2018-08-09 20:22:43 UTC
ugh conflict. fixing

Comment 20 CFME Bot 2018-08-16 20:11:08 UTC
New commit detected on ManageIQ/manageiq/master:

commit 9a63e127f290f8ef34f4c81590dd8b33664f312c
Author:     Keenan Brock <keenan@thebrocks.net>
AuthorDate: Mon Aug 13 11:27:49 2018 -0400
Commit:     Keenan Brock <keenan@thebrocks.net>
CommitDate: Mon Aug 13 11:27:49 2018 -0400

    Converge request user roles

    We introduced feature miq_request_superadmin in f6c02e81 / #17444 
    The feature miq_request_approval already existed.
    Merging the 2 together.

    This fixes an inconsistency between API and UI
    The issue existed before this feature was introduced
    so this works with 17444 to fix the BZ

 app/models/miq_product_feature.rb | 2 +-
 db/fixtures/miq_product_features.yml | 4 -
 db/fixtures/miq_user_roles.yml | 2 +-
 3 files changed, 2 insertions(+), 6 deletions(-)

Comment 22 CFME Bot 2018-08-17 11:02:53 UTC
New commit detected on ManageIQ/manageiq-ui-classic/master:

commit d4f9835524a8e3fcd312a01e07e36cf500568dcd
Author:     Keenan Brock <keenan@thebrocks.net>
AuthorDate: Thu Aug 16 15:20:57 2018 -0400
Commit:     Keenan Brock <keenan@thebrocks.net>
CommitDate: Thu Aug 16 15:20:57 2018 -0400

    use request_admin_user

    use helper method instead of calling out the miq_request_approval role
    (yes, this is being corrected in this commit)

 app/helpers/application_helper/button/miq_request_delete.rb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

Comment 23 Joe Vlcek 2018-08-17 16:35:00 UTC
*** Bug 1542810 has been marked as a duplicate of this bug. ***

Comment 25 CFME Bot 2018-08-21 15:14:16 UTC
New commit detected on ManageIQ/manageiq-api/master:

commit a88382bfb8da9d2066f9b944550968e03286dcb0
Author:     Keenan Brock <keenan@thebrocks.net>
AuthorDate: Thu Aug  9 16:24:55 2018 -0400
Commit:     Keenan Brock <keenan@thebrocks.net>
CommitDate: Thu Aug  9 16:24:55 2018 -0400

    Change request_controller special privileges

    bf3b8020 moved us away from user.is_admin?
    This is based upon the miq_request_superadmin feature.
    The UI used a different feature, miq_request_approval.

    This changes the feature identifier to make the UI and API the same.

    miq_request_superadmin will be deprecated

 spec/requests/automation_requests_spec.rb | 4 +-
 spec/requests/provision_requests_spec.rb | 6 +-
 spec/requests/requests_spec.rb | 4 +-
 spec/requests/service_requests_spec.rb | 4 +-
 4 files changed, 9 insertions(+), 9 deletions(-)

Comment 26 Keenan Brock 2018-08-21 19:31:00 UTC
API, UI, and master have been merged.

master (5.10) has this functionality. a) admin functionality for reports
and requests has been pulled moved over to roles. These PRs convert the 
role that is actually used.

If you want 5.9.5, please mark this as a higher priority.
This is more invasive of changes - went over with GreggT and the
risk outweighs the priority.

Comment 28 Antonin Pagac 2018-10-11 14:22:41 UTC
Testing setup:
users: admin, superadmin, user
service requests:
 - one created by admin
 - one created by superadmin
 - one created by user
user groups:
 - modified operator with Services -> Requests -> All enabled (with Operate)
 - reader role with Services -> Requests -> View only
 - support role without any relevant permissions

API Testing with:
curl -k -L "https://<username>:<password>@<IP>/api/service_requests/" -H 'X-MIQ-Group: <group>'

This is the behaviour I'm seeing with
 - with the modified operator role, user is able to see all three requests
   - in the API: "name":"service_requests","count":3,"subcount":3
 - with the reader role, user is able to see only request made by that user
   - in the API: "name":"service_requests","count":3,"subcount":1
 - with the support role, user sees nothing
   - in the API: "error":{"kind":"forbidden","message":"Use of the read action is forbidden" ... }

The API is consistent with the UI, giving the same results for the same groups.

Comment 31 Antonin Pagac 2018-10-17 09:19:45 UTC
Marking as verified.

Comment 32 errata-xmlrpc 2019-02-07 23:03:30 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.


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