Currently, there is a very long table of permissions in the docs: https://docs.gitlab.com/ee/user/permissions.html As we move toward customizable roles, we would expect every row in this table to be reflected in the custom role table. Before we dive into custom roles, consolidating this table would be helpful both from a backend engineering perspective (fewer permissions to customize) and probably for customers too. This was also mentioned in the Iteration office hours meeting with @hsutor presented the technical MVC plan for custom RBAC. ### Updated problem statement and proposal as of 10-11-2022 ##### [✏️ Figma link](https://www.figma.com/file/RVoAvesql5zkYPZHPbNJ3J/Reducing-permissions-to-associated-groupings?node-id=0%3A1) ### Problem From our previous issue we have identified further need to group and connect permissions based on hierarchical constraints. Currently our permissions are based individually on an object feature/behavior/action. Example of the current problem: > If I disable `View project code`, subsequently an affected user should no longer have access to MRs, snippets, the repo, or anything else that project code would connect with. However that individual permission does not connect to the others in our current system. ### Proposal Investigate these connections and create a linking structure to reduce permission disassociation and complexity. ### MVCs 1. additive permissions - adding a permission to a gitlab defined role (guest/dev/reporter...etc) 2. can we introduce linked permissions in the [current prototype](https://gitlab.com/gitlab-org/gitlab/-/issues/370729) visuals 3. do we need to expand this for better UI