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): 5.9.3 How reproducible: Always 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
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.
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!
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.
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.
ugh conflict. fixing
https://github.com/ManageIQ/manageiq-api/pull/447
https://github.com/ManageIQ/manageiq/pull/17849
https://github.com/ManageIQ/manageiq/pull/17858
https://github.com/ManageIQ/manageiq-ui-classic/pull/4487
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/9a63e127f290f8ef34f4c81590dd8b33664f312c commit 9a63e127f290f8ef34f4c81590dd8b33664f312c Author: Keenan Brock <keenan> AuthorDate: Mon Aug 13 11:27:49 2018 -0400 Commit: Keenan Brock <keenan> 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 https://github.com/ManageIQ/manageiq/pull/17444 https://bugzilla.redhat.com/show_bug.cgi?id=1608554 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(-)
https://github.com/ManageIQ/manageiq-ui-classic/pull/4489
New commit detected on ManageIQ/manageiq-ui-classic/master: https://github.com/ManageIQ/manageiq-ui-classic/commit/d4f9835524a8e3fcd312a01e07e36cf500568dcd commit d4f9835524a8e3fcd312a01e07e36cf500568dcd Author: Keenan Brock <keenan> AuthorDate: Thu Aug 16 15:20:57 2018 -0400 Commit: Keenan Brock <keenan> 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) https://bugzilla.redhat.com/show_bug.cgi?id=1608554 app/helpers/application_helper/button/miq_request_delete.rb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
*** Bug 1542810 has been marked as a duplicate of this bug. ***
https://github.com/ManageIQ/manageiq-api/pull/454
New commit detected on ManageIQ/manageiq-api/master: https://github.com/ManageIQ/manageiq-api/commit/a88382bfb8da9d2066f9b944550968e03286dcb0 commit a88382bfb8da9d2066f9b944550968e03286dcb0 Author: Keenan Brock <keenan> AuthorDate: Thu Aug 9 16:24:55 2018 -0400 Commit: Keenan Brock <keenan> 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 https://bugzilla.redhat.com/show_bug.cgi?id=1608554 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(-)
API, UI, and master have been merged. Summary: 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.
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 5.10.0.19: - 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.
Marking as verified.
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. https://access.redhat.com/errata/RHSA-2019:0212