Managing groups, users and their roles and permissions

Question

I'm working on improving the current layout for managing group and user permissions - mainly the presentation of these things.

The way it currently works is that all permissions from a group (Read/Write or both) are propagated to all users within that group (illustration below):

We are using tabular layout (and we want to stay with it) - when we click on a group, we see the users list in that group and we can revoke/give permissions to that group and users.

Here comes the first change -

We don't want to revoke permissions for users belonging to the group. All permissions should propagate from the group they belong to (so the only option to revoke a user's permissions would be to remove him from the group). Since we are giving up the exclude mechanism, I thought that the R and W buttons next to the users should no longer be clickable - they should be grayed out, so that the user can only check which users are in the group, but they cannot revoke the user's permissions:

But here comes another problem that I do not know how to solve - so I want to get some advice.

Our environment works in such a way, that a user can be in several groups at once (this is normal). But apart from that users and groups can have certain roles - I don't know if it's not a bit of a departure from the standard RBAC (Role-based access control) model - because here both group and user can have some roles. The same with permissions - a user can have permissions granted from another group, or from himself.

In this case we may have a case where a user has his own permissions, but at the same time belongs to a group - I think it should be marked somehow that this user doesn't propagate only permissions from the group, but also has his own permissions - maybe with some color on the R/W icons? To distinguish him from users who do not have their own permissions at user level, but inherit them from the group. I'm talking about presenting in some way the scope of these permissions.

Additionally, it may happen that a user belongs to e.g. 2 groups (or more) - in one group he has all the permissions, and in the other he has none (because the group has neither R nor W permissions) - should it be noted that the user has permissions, but not specifically from this group (but from another)?

Side question: What if a user belongs to several groups where permissions (or even roles) are mutually exclusive? I was thinking about making the sum of permissions/roles in this case - IMO the best solution (although maybe someone has some other).

Thank you in advance for all the help (and for reading this whole post), sorry for those illustrative drawings - as I mentioned, they are only illustrative :)

Answer 1

It sounds like there is a risk of either a user being given permission that they shouldn't have because of a conflict in the rules governing different groups and roles, or that it is impossible for a user to be given permission when they should be able to.

Before you try to represent all of this information visually, first consider mapping out a matrix of all the groups and roles, and understand the different types of combinations that are permissible so that you can fully understand the relationships and dependencies.

Once you have done this, you might end up with no conflicts whatsoever (although you have already said that there will probably be some). But this allows you to understand which person understand what circumstances may have to carry over their permissions from one group to another (because the role has greater priority), or that they have to fall back to the permissions specified by the group (because the group has greater restrictions).

Then once you fully understand all the combinations, then you can work out the optimal way of displaying all of the information, possibly encoding this information as a mixture of colour and symbol.

For example, you might indicate that a group will override all existing user permissions regardless of the role. Or that a role will override all existing group permissions. Or that a group will allow a specific role to override existing user permissions, etc.