Fix display of indirect access permissions. #4529
Conversation
|
Before this patch, bob and fred would be shown with just |
awx/ui/client/src/access/rbac-role-column/roleList.directive.js
Outdated
Show resolved
Hide resolved
|
Note: this patch does not address awx-pf/ui-next at all, sorry. |
|
Build succeeded.
|
awx/ui/client/src/access/rbac-role-column/roleList.directive.js
Outdated
Show resolved
Hide resolved
|
cc @AlanCoding |
|
Before this change:
After this change:
The first problem is that system administrators are now shown as ADMIN, which I don't like. System auditors may have a similar issue.
The team entries all have tooltip text. None of the indirect access forms do, but there is more information available from the API that could at least do a little to address the real issue that the user isn't getting enough information to act (to revoke permissions, for example). |
Will investigate. |
|
Updated. Erred on the side of excessive comments, because RBAC. Now, for the following:
|
|
Build failed.
|
For indirect roles, we need to actually show the derived roles, not the details of the role that gives us the derived roles. This means that we can get multiple derived roles from a single indirect role, so we have to expand the list.
|
Build succeeded.
|
|
The specific instructions for delegating permissions have become too much for me. I have written this script to fully populate the permission access types for an organization. def test_full_house(self, factories):
"""Makes every object in an organization and delegates all permissions to everything"""
o = factories.organization(name='Full house!!! {}'.format(random_title()))
print('Adding people to organization roles, org name: {}'.format(o.name))
for role in o.get_related('object_roles').results:
u = factories.user()
role_field = role['name']
o.set_object_roles(u, role_field)
if role_field.lower() not in ('admin', 'member'):
team = factories.team()
o.set_object_roles(team, role_field)
to = team.ds.organization
u2 = factories.user()
to.set_object_roles(u2, 'admin')
u3 = factories.user()
team.set_object_roles(u3, 'member')
u4 = factories.user()
team.set_object_roles(u3, 'admin')
print('Creating Resources:')
for res in dir(factories):
if res.startswith('__') or res in ('clear', 'copy', 'fromkeys', 'get', 'items', 'keys', 'pop', 'popitem',
'setdefault', 'update', 'values',
'access_token', 'ad_hoc_command', 'credential_type',
'group', 'host', 'instance_group', 'inventory_source',
'organization', 'workflow_job_template_node'):
continue
print(' {}'.format(res))
if res == 'job_template':
obj = factories.job_template(project=factories.project(organization=o))
else:
obj = getattr(factories, res)(organization=o)
if res not in ('user', 'job_template'):
assert obj.organization == o.id
if res not in ('user',):
if 'object_roles' not in obj.related:
print(' resource {} does not have roles??? okay?'.format(res))
continue
obj_roles = obj.get_related('object_roles').results
for role in obj_roles:
if res == 'credential':
u = factories.user(organization=o)
team = factories.team(organization=o)
else:
u = factories.user()
team = factories.team()
role_field = role['name']
obj.set_object_roles(u, role_field)
obj.set_object_roles(team, role_field)
to = team.ds.organization
u2 = factories.user()
to.set_object_roles(u2, 'admin')
u3 = factories.user()
team.set_object_roles(u3, 'member')
u4 = factories.user()
team.set_object_roles(u3, 'admin')For a given role, you can have direct access to that role. Alternatively, you can be a member of a team, alternatively, you can be the admin of that team, alternatively, you can be org admin for the team's organization. Repeat for every possible role for every possible type of resource. Here is prior behavior before this PR for a job template (the list is very long, this is just a part of it):
Your PR is effective in converting the incorrect "ADMIN" entries to things like "READ" or "EXECUTE", but this still leaves the user with no options and no information. Basically, this is not using the access list at all, all it's doing it echoing out the permission levels with nothing else. This is still a very frustrating situation for the user. I made a PR to your branch: https://github.com/wenottingham/awx/pull/1 This adds the most basic tooltip that I can conceive of. Here is your PR combined with that change:
This at least gives the user a chance at figuring out who to talk to about why the permissions are the way they are. Note that the organization mentioned in the tooltip is not the organization of the JT's project or inventory. |
|
I made a small error in the script, the 2 instances of |
There was a problem hiding this comment.
See https://github.com/wenottingham/awx/pull/1, the current form would still be very hard for the user to cope with.
|
Updated based on Alan's PR:
|
|
Build succeeded.
|
|
Yeah that looks pretty good. The icon follows the parameters of the solution discussed with @jlmitch5. If he's happy with this, your screenshot demonstrates enough cases for me to say shipit. |
|
conceptually I think this make sense, the tooltip only shows for the ones that are indirect right? cc @trahman73 about the look of it |
|
@jlmitch5 works for me |
|
Build succeeded (gate pipeline).
|
For indirect roles, we need to actually show the derived roles, not the
details of the role that gives us the derived roles. This means that
we can get multiple derived roles from a single indirect role, so
we have to expand the list.
UI-only implementation of #4514
Will help with #3903 and #4108.
Example for an inventory:
'admin' has indirect access by being the sysadmin.
'joe' has indirect access by being an admin of the org the inventory belongs to.
'fred', from outside the org, has been granted 'read' and 'update' explicitly to his outside-the-org team.
'fred' and 'bob' are org admins of fred's org, and therefore get indirect access to the team permission of fred's team.