Lead the design effort to build a customizable permissions system, off of the current static permissions and roles framework.
This project was a massive effort, involving may parts of the organization, as the permissions architecture touches many aspects of platform. The origins of the project come from enterprise organizations requiring stronger access controls for their development environments. Organizations such as financial, or governmental organizations are often held to various regulatory and compliance controls where having the standard 5 GitLab roles leaves too much access to various projects or features, causing these organizations to fall out of compliance.
You can view the detailed work here. You can also view a playlist of videos I created on the whole process up to this point.
Customizable permissions has been a high priorty request for various enterprise users, so there was already an known user need for the feature. I began my work by investigating what situations and workflows organizations felt were insufficiently protected based on our default system of 5 user permission levels. As I got deeper into the research I determined that many other teams at GitLab were persuing customizable settings or expanded features in an effort compensate for these failings in our permissions model.
We created a “design pod” where 3 designers, and various stake holders would meet to discuss the scope of the problem and how to solve it. In the initial phase of the design pod, the work was split evenly. After we had arrived at an initial solution proposal and wireframe, I took over as DRI to continue the validation and user feedback research to fully build out the new customizable permission system.
After my initial round of testing, I discovered that there was a hidden problem we would need to resovle before we could move forward with development. The current GitLab permissions were set as individual permissions tied to individual features. The problem in a customizable permissions model is that there needs to be connections for permissions that react to one and other. If an admin disbables a higher level permission, every permission that relies on that permission being active would also need to be disabled as well.
You can view a detailed investigation with our engineers on this topic below.
In tandem to my stakeholder and user research, I was working with our engineers to understand the scope of the problem. I discussed with them the concerns around permissions linking and grouping and how we could resolve that. Engineering proposed a small MVC that could be tested via API only so that there would be no need for front end interaction. They suggested merging permissions as part of the grouping process. Where merging permissions would reduce the number of permissions that needed to be grouped and linked and subsequently reduce the complexity. This proved to be a valuable first iteration because it allowed us to test:
Merging permissions
Metrics generation and usage monitoring
Security validation
Currently this feature is live and is being tested to see how the system response to this new permission model.
You can watch the video below where I discuss the merging and grouping investigation in detail with our engineers.