I am a part of a GitHub organization. I created a private repository inside this organization. Now, I see that all members of the organization get read access to it by default; however, I only want to collaborate with a few of them and do not want others to have any access to the content of this repository at this point in time. Is it possible to do so?
This is possible.
WIth teams
First, the base permission of an org must be set to No permission. Then you need to make a team with the people you want to have read access or higher. Then you need to add the team and give them the access level you want them to have on the Collaborators and teams page in the settings for the repository.
Without teams
First, the base permission of an org must be set to No permission. Then go to the Collaborators and teams page in the settings. Then add the users you want to have access to the repository and give them the access level you want them to have.
Related
I am using Github Enterprise and would like to give other teams access to my repository.
However I don't want those teams to see the repository content, I want them to be able to see ONLY a specific file or a subdirectory (and its content).
Is that possible ?
You'll find documentation on access permissions here. The access permission model is different for repositories owned by user accounts versus those owned by organization accounts. However, in neither of those models is there a provision for providing read access to only a part of a repository. Read permission grants read access to the entire repository.
There are probably a number of creative ways to achieve the effect you're after. One would be to set up an automated process that clones your first repository, copies the files or subdirectory of interest to a second local repository, and then pushes any changes in that second repository back to GitHub Enterprise. You'd provide your other teams read access to that second repository, but not the first.
is there a way to limit new repositories creation for all users except for admins in an organization?
I found this article on Github, but this restricts the repository type. I am looking for a way to prevent users to create any new repository, unless an admin in the same organization approved.
Is it even possible with Github?
You were close to the solution. There is actually a link to another section in the documentation you shared named Enforcing repository management policies in your enterprise account with a specific section Enforcing a policy on creating repositories.
There, you'll see that you can choose whether members can create repositories in your organization.
Here is the step related to it:
I am trying to understand the complete purpose of organisations in ADO. What I have understood is that an organisation groups projects, defines resources, extensions, billing, etc. that is related to the organization.
I am struggling with the user part of an organization. I can add users to an org giving them an access level. But I can also add users directly to a project without adding them to an organization at all.
What is then the consequence of this? Is then access level by default stakeholder for those users?
Thank you
You can add people to projects instead of to your organization. Users
are automatically assigned Basic features if your organization has
seats available, or Stakeholder features if not.
For this please refer to the Note of this document.
When you add members to projects and you don't have billing set up, Basic access is automatically assigned, until you run out of seats available. When you add members to projects and you do have billing set up, Basic access is assigned only if your default access level is set to Basic. Otherwise, project members are assigned Stakeholder permissions.
You can refer to Add members to projects or teams for details.
If you add an user to a project that user will be added to the organisation as well. At least when the said user first logs in. The user will get the access level you define as default.
Say I make an organization, and set someone else to owner. Will they be able to remove me from that organization? Or are there special elevated perms for the "original" owner?
I'm not sure if StackOverflow is even the right place for this question, but I haven't been able to find anything about this online.
Yes, once you make a user owner of your organization, user gets all the permissions as you. So, user can remove you from organization.
Github can't recognize you as Original owner. There are only two possible roles, OWNER and MEMBER.
Depends what you want to do. If you want them to be able to add/remove other members without giving over full organisation access you try to add a team, add the repositories you want to that team with write access, then make the user a "maintainer" of the team which should allow them to add/remove users and therefore manage write access to particular repositories.
https://help.github.com/en/github/setting-up-and-managing-organizations-and-teams/permission-levels-for-an-organization
We have quite a few repositories in our organization, and we are constantly adding more. We also have a few different teams - Superusers, Developers, Contractors, etc. I want every newly created repository to automatically assume default permissions, like Superusers get automatic admin access to the repo, Contractors group gets just read access, etc. Is it possible to set that up? Is there a setting somewhere that I missed? And if there's not a way to do that, is there a way to batch apply a permission for one group to all repos within an account?
Update June 2017: with nested teams, you now can associate permissions to sub-teams, which could help group of users to have the correct right regarding a repo part of the organization.
Original answer (Apr. 2016)
Is it possible to set that up?
I did not see a way through the native GitHub web GUI administration pages.
And "permission" is deprecated when creating a team.
What you could consider though is a webhook listening for a an event, like a repository event.
That script listening to the event could then use the Team API to update the permission of the teams (according to their names) for the newly created repo.