Create a new role management feature that can add and modify varying admin roles

[calisio]

Overview

Our platform users require different permissions for specific pages. Currently, we have only two roles—Student and Admin. However, varying levels of admins need different access rights. For example, a Super Admin might have access to all pages, while a Teaching Assistant might only have access to the student list to reset passwords.

We need to add a feature allowing certain users to create and modify roles with different permissions. A facility Super Admin might choose to add a new role for an Activities Coordinator or an Instructor and grant them certain permissions. This can be implemented through a Role Management page, where authorized users can create new roles and update existing ones.

Implementation

Designs for Inspiration

Implementation options range from granular control over permissions to more simplified approaches. Below are some design inspirations from Dribbble for user role management systems.

Fig 1. Credit to Ebru Gizem Temur. Design available at https://dribbble.com/shots/21488945-User-Role-Management.

Fig 2. Credit to Eugen Eşanu. Design available at https://dribbble.com/shots/20002701-User-role-management.

Fig 3. Credit to Ajay Shekhawat. Design available at https://dribbble.com/shots/16427340-User-Management-Admin-Portal-Access-and-Permissions-Screen.

Potential Options

Option 1

Table view with checkmarks and more in depth control of access for each page.

Pros:

• Allows for the admin to specify which parts of each page a user might have access to. For example, a TA might have access to adding a new student but should not be able to add a new admin user.
• Allows the modifier to easily compare which roles have which permissions.

Cons:

• Can become very overwhelming in the frontend due to the high volume of checkboxes.

Option 2

Table view with checkmarks but simpler- gives access to the individual on an page by page basis.

Pros:

• This would lower the density of checkmarks

Cons:

• would really restrict the permissions that a role would receive (full page access or no page access)
  • For example, a teaching assistant would have to be given full access to the users page. they then would be able to add a new user with admin permissions, which might be a problem. This would not allow for us to hide/show content on each page based on their role.

Option 3

Pill view of permissions

This is similar to option 3, but shows permissions in pill form to make it more digestible.

Pros:

• easy to see what permissions each role has. each pill would be colored differently so there is not a sea of permissions. less overwhelming

Cons:

• can get a little difficult to compare between roles
• The whole page is either added or deleted

Modals for adding role

Some example modals that will add roles or delete permissions.

Using Ory Keto for Role Permissions

To implement this, we must save what roles have what permissions somewhere. Ory (which also has created Hydra, what we are using for OIDC currently) has an open source solution for this issue called Keto. Keto is the open-source alternative to Google’s Zanzibar; it is a great way to keep track of users with different permissions (learn more here). A good tutorial to understand how Keto works can be found here.

Using Keto, we can keep track of access to pages without the redundancy of a sql database. Our nested structure with our current pages (restructured into some folders) looks like the following:

Using Keto’s structure, we can build out the relations between pages and our built-in roles: Student, SuperAdmin, and DefaultAdmin. An example of what an added TA role might look like is also shown below.

Next steps

This task will be broken down into smaller steps once the team has reviewed the feature and its potential implementation.

[nokierae]

This is exactly what I'd want from our RFC's going forward: In depth, but also straight to the point. I love that you gave us multiple options for the UI (I'm leaning toward option 1, but we will see what Product thinks.) Let's discuss briefly in sprint planning, and then I think this is ready to move forward with breaking into smaller tasks. Great job!

[chrissantillan]

I like Option 1, but with one suggestion: can we make each section have a checkbox (take User Management, for example), which when checked would select all the permissions within that section, and then have every permission within that section be selectable/unselectable? I'm thinking of typical software installs where you can select all the components in a package or select them individually. That way you can make a section (User Management, again) toggleable. That way it would declutter the page, as well as the Add New Role modal.

[calisio]

@chrissantillan That is a great idea. I had thought about making an overarching checkmark to select/unselect all, but the toggle view is a great addition I hadn't thought of. I'll incorporate that in the mockup!