Manage groups

Both individual accounts and teams can use groups to manage access to repositories.  Teams also use groups to grant members rights, to create repositories, and to administer the team.  Groups consist of one or more members all of which must have a Bitbucket individual account.

 Teams also use groups to grant members rights, to create repositories, and to administer the team to learn more about creating and managing groups for a team see, Managing team user groups.

This page contains the following topics:

Groups Management Controls: individual account

To manage groups, regardless of the account type, go to the Manage page (Avatar>Manage account) and choose Groups.  The Groups page for an individual account has the following controls:  (1) repository access, (2) Edit or remove a group, (3) member list; click on a user name to go to their home page, (4) remove user from group; click the x symbol to remove that member from the group. Go here to see the controls for a team.

Managing Group Access to Repositories

You use Groups to grant several users access to the repositories associated with an account.   To control access You set the value:

have permission access to this account's repositories 

If you set no access (no), none of the group members have no access to an account's repositories. Alternatively, you can set any of the following default permissions levels:

Level This permissions allows a user to do the following:
read View, clone, and fork the repository code. All public repositories grant all Bitbucket users read permissions automatically. Read access on a repository also allows users to create issues, comment on issues, and edit wiki pages.
write Contribute to the repository by pushing changes directly from a repository on a local machine.
admin Can do everything a repository owner can do. This means administrators can:
  • Change repository settings.
  • Add, change, and remove user permissions.
  • Give other users administrator access.
  • Delete the repository.

When you create a repository on an account, Bitbucket determines if the account has any groups with a default permissions (readwrite, or admin) assigned. If it does, Bitbucket adds those groups to the new repository with the default permission. If you specify no default permissions, Bitbucket ignores that group and does not add it.  If you add a new group at the account level, all existing repositories receive the new group automatically. 

Changing a group's permission at the account-level causes Bitbucket to change the permissions for that group on all an account's repositories. Repository administrators can prevent this change by setting repository-specific settings.  See Granting Users Access to a Repository for more information.  

Keep in mind the group permission applies to all members. If you give a group administrator permission to your repository, any group member can administer the repository through its Admin tab.  If you are concerned about inadvertently giving users access to your repositories, always specify no default group permissions. 

Adding a Team to a Group Has No Effect

Bitbucket allows you to add a team to a group or directly to a repository. Adding a team to a group does not give the individual team members access. It has no effect; the ability to do this is a bug.

Was this helpful?

Thanks for your feedback!

6 Archived comments

  1. User avatar

    Luis Cipriani

    As commented in a issue:

    • When I create a group, the permissions set will be propagated to all repositories that an account owns.
    • Let's say an another repository admin removes that group from the repository access list;
    • Next time I decide to change a group permissions, they will only be set in repositories that still have the group associated, and this go against the fact that the name of the permission is "have 'admin' access to this account's repositories".
    • The warning message even tell me that it is applying only to a subset of my account's repositories.

    Is this really the expected behavior of this feature?

    As an employee of a company that will need to distribute account administration between several project managers because we have ~930 private repositories, this sounds more like a information security flaw. Global permissions should be applied globally and this behavior should not change through time.

    20 Feb 2013
    1. User avatar

      manthony

      Luis,

      You are correct; model is that a group permission are set globally at the account but can be overridden on a repository. When an administrator changes the permissions associated with the group, the message tells you how many repositories are impacted; these can be a subset.  I also understand your frustration in that this is not the model you expect.

      Our team is always trying to improve our product.  I hope you have filed an enhancement request.  If you would like to participate in one of our product design UX tests you have the opportunity to do that.  Please send us an email if that sounds like something you want to do.

      Mary

      23 Feb 2013
  2. User avatar

    Anonymous

    It would be more clear if the word "default" would be used after the pull down menu to set the access level. 

    Example: Students have NO "default" access to this account's repositories.

    23 Feb 2013
  3. User avatar

    manthony

    You should file an enhancement request for this. My first reaction is that:

    have no access to this account's repositories.

    is clearer than:

    have no default access to this account's repositories.

    Can you explain what you believe having the adjective default is clearer?

    23 Feb 2013
  4. User avatar

    Joseph Keller

    Necro'd but I actually completely agree that 'default' should be there.

    Instead of being able to focus my time on important job tasks, I have to read through this page to find the single word that correctly shows what I need. All I wanted to do was create a group, add users to the group, and give the users of the group write permissions to one repository.

    Instead of knowing to set the access to 'no' for the group and adding the group to the repository, I had to spend over an hour of searching and reading documentation to understand this (seeing the word default). 

    The current way it's written is confusing and would be easily solved by having the word 'default'. It makes me think that if you select 'No' for a group, the user/group will have no access to any repository no matter what. It could also mean that those are the high possible permissions for people in the group and it can only get more restrictive when setting stuff under the repository's permissions.

    There are multiple ways to view this English and having the word 'default' is more clear than having no word at all. Can you explain how having an adjective is less clear than not having an adjective? Adjectives are words that describe words. It helps the reader understand the word it is describing.

    27 May 2015
Powered by Confluence and Scroll Viewport