Access_mockups.md

Problem - access display

This is split out from:

ansible/django-ansible-base#150

Requires adding new API endpoint(s), and corresponding 1-to-1 presentation in the UI, that shows access to an object.

This is not the same as showing the permissions that a user or team has (user/team permissions). Clarifying language with reference to old AWX UI:

• access display: /api/inventories/42/access_list/
• user permissions: /api/v2/users/9/roles/
• team permissions: /api/v2/teams/11/roles/

object-role presentation (not considered, not user-oriented)

This shows entries of the ObjectRole model, which is only used internally now. An object-role would correspond to the "old" controller roles, like job template admin_role. Role assignments are the through-model between object-roles and users or teams. So this table shows it fairly directly as it exists in the database.

Advantages:

• very truthful representation of what is in the database
• actually extremely complete in what it displays
• URL construction has a lot of options

Disadvantages:

• does not expand the users of a team, seeing QE members would require click-through

Role	Permissions	Users	Teams
org-admin	change,delete,execute,view	bob,alice
org-auditor	view		BU,QE
jt-execute	execute,view	joe

Role assignment presentation (rejected in favor of single-tab)

This proposes only an extremely minor modification of what we are displaying now in the UI. That change is to add indirect role assignments, thus the inclusion of org-admin below.

Advantages:

• minimal changes from the current UI
• shows exact permissions that a user has

Disadvantages:

• can not reasonably combine team & users in same view
• in team view, click-through required to see QE members, for example
• repeats users in list, which will confuse someone

Role	User	Permissions
org-admin	bob	change,delete,execute,view
org-admin	alice	change,delete,execute,view
jt-execute	joe	execute,view

and separate list for teams

Role	Team	Permissions
org-auditor	BU	view
org-auditor	QE	view

Role assignments fudging team permissions (runner-up)

This has appeared in mockups from the UI perspective.

The technical details are speculative, but this would presumably be listing the RoleUserAssignment model. The filtering would be accomplished by crossing over related role__permission_partials, with that being set equal to 2 criteria, matching the GenericForeignKey used by RoleEvaluation model, so that we only match evaluations to those targeting the (pk, type) of the current object.

User	Permissions	Role	Via Team
bob	change,delete,execute,view	org-admin
bob	execute,view	org-jt-execute
alice	change,delete,execute,view	org-admin
joe	execute,view	jt-execute
chris	view	org-auditor	QE

NOTE: The permissions are not just want's in the role, but filtered to the current type. For instance org-admin lists a lot of permissions, but only a small number are relevant to the context.

NOTE: Here, chris is has team-member role to the QE team, and the QE team has the org-auditor role to the JT's organization. The team role assignment (and its permissions) are presented.

User role intersection (top, currently planned)

This is mostly a dumb copy of what we have in controller. This gives a presentation of users, based on the standard filtering mechanisms. But in addition to that, it must show related roles based on related intersection, used by that filtering mechanism. So you can summarize by saying this is a users list plus contextual information based on the object.

Advantages:

• No click-through to see all users with permissions

Disadvantages:

• Need click-through to see team inheritance mechanism, like QE having org-auditor
• Empty teams are dropped on the floor, unresolved bugs filed on this
  • Needs answer, probably results in a separate team view anyway
• Roles list unbounded but unreasonable to paginate
• Very challenging to agree on detail to display, easy to ask for performance-killing annotations

User	Permissions	Roles
bob	change,delete,execute,view	org-admin, org-jt-execute
alice	change,delete,execute,view	org-admin
joe	execute,view	jt-execute
chris	view	org-auditor (QE)

Full graph view

I described this in the prior AWX issue.

ansible/awx#3600

It is a bad idea, inconsistent with the rest of the UX. The front-end complexity of a graph presentation led me to give a solution that condenses paths in the graph to display with arrow notation on a row-by-row basis. Like user->roleA->roleB->object. This is computationally heroic, and this is not a compliment.

However, it worked, and it might be good as a tool to have around, like as a CLI tool.