Problem Description

Users currently assign global and object permissions directly to groups. All of these existing permissions must be migrated into roles.

Proposed Solution

There are 3 potential solutions to this problem:

Let's say I have group foo with model permissions for create-bar and update-bar.

1. Create a role for each group that has the all of the permissions that the group used to have. In this scenario we'd, create role group-foo, assign create-bar and update-bar to the new role, and assign the new role to foo.
2. Create a role for each permission. In this scenario we'd create a role called permission-create-bar and permission-update-bar and assign both of the new roles to foo.
3. Attempt to match a group's permission matrix to a set of system roles. This would attempt to assign a system role that has permissions for create-bar and update-bar to foo.
4. Combination of 1 and 3

Each approach has it's advantages and disadvantages. 3 would provide the best user experience, but would be buggy, and potentially impossible to implement since system roles are only created in a post migration hook. 1 and 2 will both create a lot of annoying default roles that will make it difficult to search for roles that user's might actually care about. 2 would likely created fewer roles, but also bypasses the purpose of roles in the first place.

Global permissions

Global permissions are ones that grant a user access to all objects of a specific type. For example granting a user global namespace permissions would allow them to edit all namespaces in the system.

At the moment option 1 seems to be the most sensible for global permissions. It will preserve each groups permissions set exactly as the user has already defined.

Object Permissions

We currently have two resources that we set object permissions on. These are collection and container namespaces. Since both of these have a limited set of options for permissions, option 3 seems reasonable. To accomplish this we would create a container-namespace-admin role and a collection-namespace-admin role which would each have all of the permissions that we currently expose for each of these objects. During the migration, any group that has one or more of the permissions would receive the role.

The disadvantage with this approach is that we may accidentally escalate user's permissions if the customer intended for a user to only have a subset of the permissions that are available on each object, so further analyses on this may be required.