A Role can have many Permissions, and a Permission can belong to many Roles. I am designing an interface that allows the user to manage a specific role, and any associated permissions at the same time:
The idea is that the user should be able to add an existing permission to the role, but they should also be able to create an entirely new permission and associate it with the role.
The situation is confounded by the fact that when you create a new permission, you need to enter some additional information. When you use an existing permission, that information is already present (though perhaps you would want to edit it).
I see two conflicting design priorities here:
There are up to six different actions that I might want to represent with my "permissions" widget:
- Create new permission and attach to role
- Attach existing permission to role
- Detach permission from role
- Delete permission (and also detach from all roles)
- Edit permission (changes will affect other roles)
- Copy permission, attach to role, and then edit
Some of these actions can affect other roles, thus creating unintended consequences. This could be a major problem, especially when we're talking about such a sensitive set of operations as managing access control.
Representing these as distinct actions is difficult as well. Does a trashcan icon mean "detach this permission from this role", or does it mean "delete this permission entirely?"
By and large, most permissions will be assigned to a role when the role is created. It is a lot easier for an admin to directly create any new permissions that they need when they create the role, rather than having to go through a separate "permissions" interface.
What would be a good way to handle this tradeoff?