Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.
Red Hat Satellite engineering is moving the tracking of its product development work on Satellite to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "Satellite project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs will be migrated starting at the end of May. If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "Satellite project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/SAT-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.

Bug 1406433

Summary: Non-admin user with correct permissions unable to list users from webui and with /api/v2/users REST API.
Product: Red Hat Satellite Reporter: Mahesh Taru <mtaru>
Component: Users & RolesAssignee: satellite6-bugs <satellite6-bugs>
Status: CLOSED DUPLICATE QA Contact: Katello QA List <katello-qa-list>
Severity: medium Docs Contact:
Priority: medium    
Version: 6.2.5CC: achadha, bbuckingham, dhlavacd, dlobatog, jcallaha, mhulan, mtaru, ssherkar
Target Milestone: UnspecifiedKeywords: Reopened, Triaged
Target Release: Unused   
Hardware: x86_64   
OS: Linux   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2017-02-21 12:05:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Mahesh Taru 2016-12-20 13:57:52 UTC
Description of problem:
When using non-admin user which have viewer role assigned, unable to list all users from satellite on webui or with API.

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

How reproducible:
I was unable to reproduce.

Steps to Reproduce:
1. Create normal users with following roles.
- edit hosts
- view hosts
- viewer
2. Login with normal user to satellite webui --> Administer --> Users
3. Try API https://satellite.example.com/api/v2/users
4. With Admin account it lists all users but with non-admin user it lists less number of users. For ex: Total 11 users are present.
Admin is able to see all whereas normal user is able to see 7.

5. Only one organization and all users are under same organization.

Actual results:
Normal user unable to see all users even though correct role is assigned.

Expected results:
Should be able to see all users.

Additional info:

Comment 3 RHEL Program Management 2016-12-21 11:22:48 UTC
Development Management has reviewed and declined this request.
You may appeal this decision by reopening this request.

Comment 18 satish sherkar 2017-01-27 14:48:46 UTC
Hello Team,

Addition to this Bugzilla, When non-admin user is login without Administrator Permissions not able to view his own user information from "My account" and "Administrator >> Users ", Getting below error Message.

~~~~~~~~~~
Oops, we're sorry but something went wrong PG::Error: ERROR: for SELECT DISTINCT, ORDER BY expressions must appear in select list LINE 1: ...ocation')) ORDER BY filters.role_id, filters.id, "roles"."n... ^ : SELECT DISTINCT "filters".* FROM "filters" INNER JOIN "filterings" ON "filterings"."filter_id" = "filters"."id" INNER JOIN "permissions" ON "permissions"."id" = "filterings"."permission_id" INNER JOIN "roles" ON "filters"."role_id" = "roles"."id" INNER JOIN "cached_user_roles" ON "roles"."id" = "cached_user_roles"."role_id" LEFT JOIN taxable_taxonomies ON (filters.id = taxable_taxonomies.taxable_id AND taxable_type = 'Filter') LEFT JOIN taxonomies ON (taxonomies.id = taxable_taxonomies.taxonomy_id) WHERE "roles"."builtin" = 0 AND "roles"."id" IN (6, 5, 1, 18, 17, 19, 16, 15, 10, 8, 7, 4, 21, 20, 12, 2, 3, 11, 9) AND "cached_user_roles"."user_id" = $1 AND (permissions.resource_type = 'Role') AND (permissions.name = 'view_roles') AND (taxable_taxonomies.id IS NULL OR (taxonomies.type = 'Organization') OR (taxonomies.type = 'Location')) ORDER BY filters.role_id, filters.id, "roles"."name" ASC
~~~~~~~~~~
Please let me know if you need any information.

Regards,
Satish Sherkar

Comment 19 Marek Hulan 2017-01-30 09:08:06 UTC
Satish, I believe you just hit BZ 1392513 that should be already fixed in 6.2.7. Please don't combine two different error messages in one BZ, it's hard to track the progress in such case.

Comment 20 Daniel Lobato Garcia 2017-02-21 12:05:54 UTC
Marek and Satish,

I had a call with this customer yesterday to fix https://bugzilla.redhat.com/show_bug.cgi?id=1408135

We explored also what was causing this bug. The response was fine, the issue is that the UI does not reflect properly what the locations/organizations are for users who have none and are 'owners' of hosts.

e.g: 

For an admin api/v2/users returns 4 users (includes the ones without orgs/locs)
For a regular user api/v2/users/ returns 2 users (the other 2 did NOT have orgs/locs)

However, on the UI if you clicked on those users, Location/Organization tabs you'd see "Default Location" - "cannot be unassigned because it's used by a host (or something like that)". On the UI it looks like it's assigned to the user but you can't remove it. On foreman-rake console, it becomes clear that the user does NOT have the taxable_taxonomies association. 

It's the same bug as in https://bugzilla.redhat.com/show_bug.cgi?id=1228365 for hostgroups. We agreed during the call to make this one a duplicate and track the status of this through (https://bugzilla.redhat.com/show_bug.cgi?id=1228365). 

This already has a patch (for other object affected by this 'ghost association', hostgroups) upstream https://github.com/theforeman/foreman/pull/4136 - but it has to be updated to include host.owner.

*** This bug has been marked as a duplicate of bug 1228365 ***