How to restrict a member's access

How it works#

Access in an organization is built from three sources. The broadest of them applies:

1. Base permission — what any member sees in all the organization's repositories: none, read, write or admin.
2. Teams — a team is given access to individual repositories with a role; a person has it while they are on the team.
3. Direct — access to one repository for a specific person.

Organization owners are always admins of all its repositories.

Rights on issues are the same as on the repository: whoever sees the repository sees all its issues. Some issues inside one repository cannot be hidden separately — same as on GitHub. What each role can do is in the table on the repository members and roles page.

Step by step: an intern sees only some repositories#

1. Close everything by default. When creating the organization pick «Members see only what they are given», or later: Organization settings → Member privileges → base permission «None». Now a member without grants sees only public repositories.
2. Create a team. The Teams tab → New team, for example «Interns».
3. Give the team the repositories it needs. In each such repository: Settings → Access → at the bottom of the table pick the team and a role.
   • read code and issues, open and comment on issues — Read;
   • manage issues (labels, assignees, closing) without changing code — Triage;
   • change code — Write.
4. Invite the person to the organization with the «Member» role and tick the «Interns» team right away — on accepting, they join it.
5. Check. People → the person's row → Repository access: the needed repositories with the team's role, other private ones — «no access».

If some issues must be closed#

Move the issues not everyone should see into a separate private repository — for example, company/internal — and give it only to the right team. Shared issues stay in the main repository. This is GitHub's approach: rights live at the repository level, and that makes them easier to check.

A contractor who needs one repository#

Do not invite them to the organization: give them access directly under the repository's «Access». They become an outside collaborator — they see only that repository and do not see the organization or its members. Outside collaborators are listed on the People tab.

When a person leaves#

People → the member menu → Remove. Immediately gone:

• the organization membership and organization roles;
• membership in all its teams;
• direct grants in its repositories.

Nothing of the work disappears: the repositories belong to the organization, and all the person's commits, files, issues and comments stay in them under their name. Even if someone later deletes their files, they stay in the commit history.

Their forks of the organization's private repositories are deleted — as on GitHub: otherwise they would take the code with its whole history. The deletion goes into the organization's audit log. The same happens when a person loses access to a private repository in another way — leaving a team, a direct grant removed, a team grant removed. Forks of public repositories and their own repositories stay.

Check what a member sees#

People → the member's row → Repository access. It lists every repository of the organization, the person's role and where it comes from: base permission, team, direct grant, organization owner. An organization owner sees this page for any member, a member sees their own.

The line above the invitation form tells what a new member will see with the current base permission.

Right at creation#

Creating an organization offers the choice «Who sees what»: members see all repositories (base permission «Read») or only what they are given (base permission «None»). If interns are coming, pick the second.

Was this helpful?

Yes No