When testing the permissions for each Role, how do you know what the permissions should be for each user other than looking at the backend code? Having documentation of the permissions as they relate to all orgs features for all roles will be helpful for reviewing this PR especially any tests, for future testing and for documentation for users

For all roles including:
Owner, User Admin, Template Admins, Auditor, Organization Admin, Organization User Admin, Organization Template Admin, Organization Auditor

I don't think it really makes sense to focus on "roles", because custom roles exist. I just focused on "what permissions make sense for enabling x". a "create/new thing" button should only show up for people with the proper permissions to create a that type of thing.

A user with site wide user admin, template admin and auditor is able to successfully access an org they are not a member of without any errors. This does not seem correct.

it is correct though, that's how site wide permissions are implemented

A user with site wide user admin, template admin and auditor is able to successfully access an org they are not a member of without any errors. This does not seem correct.

it is correct though, that's how site wide permissions are implemented

The part that feels incorrect is that a user is only able access an org they are not a member if they have all 3 permissions combined (site wide user admin, template admin and auditor) if they have just 1 or 2 of them then they do not have access. It feels like that should only be for an owner role. Behavior that only happens for combinations of roles feels confusing.

after looking at the code, the new provisioners page has some deeper rooted permissions issues that probably need to be dealt with separately.

The part that feels incorrect is that a user is only able access an org they are not a member if they have all 3 permissions combined (site wide user admin, template admin and auditor) if they have just 1 or 2 of them then they do not have access. It feels like that should only be for an owner role. Behavior that only happens for combinations of roles feels confusing.

I think the real issue here is that I gave site auditorsorganizations.read to fix another issue, but site user admin and site template admin both need it as well. All of the site wide roles now have that permission, which equals them out.

Why would a site wide template admin or auditor have access to custom roles read only but not idp sync? Whereas a user admin has access to both? I would expect the template admin and auditor does not need even read access to custom roles.

For a site wide template admin or site wide auditor I am still seeing this error message for an org they are not a member of. I am expecting them to have access to members in the same way they do for an org they are a member of.

It may help to update the roles popover with information about access to provisioners, custom roles and idp sync and to be clear about ability to manage users and groups. FYI, its because of the text here that I dont think site wide template admins or auditors should be able to access members or groups in organizations.

@jaaydenh this PR is already enormous and fixes a ton of bugs. I appreciate that you want to find more bugs, but this code needs to be merged. this PR is almost two weeks old, if you have a problem with any of the changes I have already made then we can talk about those, but any further fixes need to be follow ups. I'm not gonna keep adding more and more bug fixes in one PR forever. 😅

this is not the right venue to be discussing what permissions a role should have, or to discuss if we describe built-in roles with sufficient detail, the goal here it to make sure that the correct permission is being checked in more places.

@aslilac Totally fine moving more fixes to another PR. I was imaging the goal of this PR was to correct the frontend permissions for all the built-in site wide and organizations roles.