Repository navigation
Ability to set Teams and Team Members at the Org level, not only Rulesets #690
Description
Prerequisites:
- Is the functionality available in the GitHub UI? If so, please provide a link to information about the feature.
Currently this functionality is available to set at the org level here: https://github.com/orgs/<org-name>/teams where teams can be created and members added to them.
- Is the functionality available through the GitHub API? If the functionality is available, please provide links to the
API documentation (https://developer.github.com/v3/) as well as the Octokit documentation (https://octokit.github.io/).
Yes. API functionality is available for:
- Managing teams teams: https://docs.github.com/en/rest/teams/teams?apiVersion=2022-11-28
- Managing team members: https://docs.github.com/en/rest/teams/members?apiVersion=2022-11-28
New Feature
Currently it is not possible to target any org settings except for rulesets. We would like to use the safe-settings app to also manage our teams at the org level, and manage members. These functionalities are fully available in the GitHub UI right now, and have full API support, as referenced above. If it is possible to manage teams and team members with the bot, we do not need to have org owners that can use the UI to manually manage these settings and we can use the PR approval flow to keep things consistent across our org.
Because Teams can have sub-teams, it might make sense to have the settings for teams to be its own file like teams.yml where Team name, details, members, sub-teams, etc... can be defined below nested as deeply as users might need to.
A note for project maintainers... my company needs this functionality, so I am willing to contribute these enhancements back to the safe-settings app. Ideally I would like to align with maintainers on a few implementation details (naming, should this be in the main org settings.yml or a separate teams.yml or both, etc) before moving too far forward, so that there are no annoying refactors afterwards.
Activity
brianespinosa commentedon Sep 27, 2024
@decyjphr sorry to tag you here... but I have some free time this weekend and next week that I could spend adding this functionality. I would just like to know:
settings.ymlfile or as a separateteams.ymlfile? (Separate could have a few benefits such as defining different CODEOWNERS)decyjphr commentedon Sep 28, 2024
@brianespinosa tldr; yes, go ahead with the idea.
We already have a config for Teams here
But so far we only intended to set the team permissions for repos and not manage the Team creation and Team memberships. Those were left to the Azure AD or some external system.
But we have seen requirements related to teams crop up. Here is one which I am planning to work on. So I think we might be at a point where we should consider a way to manage
teamsandteam memberships.For your question
#2, I think we should keep teams under a separate folder, perhaps,teams, similar to how we havereposorsuborgsAlso, we should consider a separate metadata.yml file which could have flags such as:
allow_only_idp_teamsthat applies to the org in general
randy-coburn-zeam commentedon Dec 6, 2024
I really like this idea and as new user I started looking for this features documentation with in about an hour after setting up my first few repos.
leinad87 commentedon Feb 12, 2025
Does this continue in the roadmap?