Managing permissions, membership, policy and teams

[jessehouwing]

I've been managing our gitHub enterprise for a few weeks now and I'm missing a lot of features in this area:

• The GitHub CLI is missing any and all features in this regard.
  • Managing team membership
  • Managing role assignments
  • Managing policy changes
• The "members" page at the org level lists all repositories a user can access, including the ones granted by teh base permission and all public repos. This makes the page almost useless to manage user access.
• The equivalent "members" page at the enterprise level is a lof better, it shows explicit repository memberships, but only lists owner/name for the repositories without allowing me to link, remove the user, or manage in any way.
• When changing any enterprise level policy, it's not (easily) possible to contact users who are likely to be impacted by these changes. A way to reach out to repo admins whose repo setting will be changed by an enterprise or org policy
• There is no "why does this user have access to this repo". Especially on the members pages this would be super useful. Is access granted by: Enterprise/org ownership? base permission? Repo visibility? Team Membership? Explicit access assignment? Security contact?
• Some policies only have an "on/off" state. For example: "✅ allow actions to edit pull requests". If I uncheck this at the enterprise/org level, NOBODY can use this feature. If I check this at the enterprise/org level, it is enabled EVERYWHERE. There is no secure by default option in this case. Other policies follow an enable/disable/unset option.
• The invite a member pop-up at the org and repo is broken in many ways:
  • When typing a username it should bubble org and enterprise members to the top.
  • It should clearly separate outside users.
  • For internal users it should show more details than just the icon and github-id.
  • It should clearly show enterprise membership, other orgs and when allowed enterprise notification email address.
• Dormancy report is only available by user interaction. Ideally there would be a way to trigger a workflow on a schedule to process the dormancy report.
• Idem for GitHub Copilot user activity in order to manage license assignments.
• The REST api docs list the statement to invoke an API using gh api, but it uses bash multi-line escapes (\), this doesn't work in pwsh and cmd on windows, making it a real nuisance to edit the statement every time I copy/paste something from the docs. It would make sense not to include the multi-line separator at all when copying the contents using the 📋 button.
• The "base permission" is quite useless. There is no way to have truly private repos without limiting default access to all internal repos. And as there is no default "everyone" team it's hard to grant access to internal repos to all. Ideally there would be a base permission for private repos as well as a base permission for internal repos. The base permission for internal repos could then also govern visibility for "enterprise members" who aren't part of the org that hosts the internal repo. The docs on "base permissions" is severely lacking in explaining what happens.

[philomory]

I wholeheartedly agree. The current permissions system seems almost precision engineered to make managing who has access to what as inconvenient as possible, to the eventual end of having you give up and just set the "base permissions" as high as you can stomach, just so you don't have to constantly manually edit everything.

The simple fact that you can't create a Team and configure it such that "this team has read access to every repository in the organization", "this team has write access to every repository in the organization", etc... it's maddening.

[jessehouwing]

I've scripted these teams now. I have a script that lops every member into it called "everyone" and a script that assigns teams to repos.

GitHub internally uses a config file that lives in Git to manage memberships and access and such, I don't think these users tend to venture into the teams section or assign permissions using the UI.

[philomory]

Sure, but then you need to run that script every time a new repository is created. Which means setting up an organization webhook, if you want to automate that. Organization webhooks aren't compatible with github actions repository dispatch, so you'll need to throw together some other place for that webhook to point (maybe a lambda function, whatever), and then ensure that auth between all these places is functioning correctly... obviously it can be done, but it's a bunch of extra work that every individual organization admin needs to do themselves, rather than just having the feature be available within Github itself, as part of the permission system.