Skip to end of metadata
Go to start of metadata

The purpose of a hosted DVCS is, in part, to allow geographically dispersed users to collaborate on code development. To do this effectively in Bitbucket, you need to understand public and private as it applies to repositories. You also need to understand what types of permissions you can grant to users in your repositories. This page covers the following topics:

Repository Creation for User Accounts and Teams

The account that creates a repository is known as its owner. An owner can be a user account or a team. Either can create unlimited Bitbucket public or private repositories. If you are a member of a team, you have the option of creating a repository under your person account or under the team account:

If a team member creates a repository for the team, the team is the repository owner and the team member is the repository creator.

Visibility is the notion that a repository is searchable through Bitbucket. Public repositories are visible to all Bitbucket users. When a private repository is created under a user account, the repository is visible only to its owner and users that owner gives access. If an account has created groups, group members automatically receive the access defined for that group. Teams typically have at least a Developers and an Administrators group.

Accounts without access cannot clone or view the contents of a private repository even if they know the repository's URL.

Permissions and Repositories

Repository owners and creators have administrative rights by default. Administrators can grant or deny other accounts access to a repository. An account plan only restricts access to private repositories. Administrators can allow 5, 10, 25, 50, or an unlimited number of users access to private repositories. For user accounts, the owner always counts as one user. For team accounts, the team account is not counted in the plan restriction.

Administrators configure the permissions associated with each user with access. Bitbucket supports the following permission levels:

LevelThis permissions allows a user to do the following:
readView 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.
writeContribute to the repository by pushing changes directly from a repository on a local machine.
adminCan 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.

Allowing or Restricting Forks

Public repositories allow public forks. To restrict forking you will have to make your repository private.

On a private repository's Admin page, in the Repository details section, you can choose one of the following:

  • No forks: just what it says, no forks of the repository can be created by anyone including administrators (who, of course, can turn forking back on if they need to).
  • Allow only private forks: will restrict any fork of the repository to remain private.
  • Allow forks: will allow forks of the repository to be created and made public.

Even after you set No forks or Allow only private forks, any user with read, write, or admin permission to your private repository can still view your repository on Bitbucket and potentially copy its code. Forking and Cloning are different actions, restricting forks has no impact on the ability to clone a repository.

Groups for Providing Access

When you create a repository, Bitbucket checks to see if the owner's account has any groups with a default permissions (readwrite, or admin) assigned. If you do, it adds that group to the new repository with the default permission. If you specify no default permissions, Bitbucket ignores that group. If you are concerned about inadvertently giving users access to your repositories, always specify no default group permissions. If you change your mind, you can always later go to the repository's Admin page and give the group access later.

Groups must be defined on your account or on teams that you administrate. If you are logged in as an individual user and create a repository for a team you administer, Bitbucket adds only the groups defined on the team account. It does not add groups defined on your individual account. As long as you have administrative rights on a repository, you can always add additional users and additional groups to a repository. 

There are two levels you can change a group, at the account level or at the at the repository level. When you change the group at the repository level, you establish repository-level group settings. You can do this by changing the permission on the group to be different than what it is on the account or by removing the group all together from the repository. Once you establish repository-level permissions for a group, they remain in effect, no matter if you later change the permissions on the account-level.

Changing a group's permissions at the account level causes the system to change the permissions only for repositories that do not have repository-specific settings. If you add a new group at the account level, all existing repositories receive the new group automatically. 

How Permissions work for Issue Trackers and Wikis

Repositories can include wikis and issue trackers. You can set the visibility (public or private) on a wiki or issue tracker independent of whether the corresponding repository is public or private. 

For wikis, the following table describes the various settings you can set and what behaviors the settings enable:

WikiRepositoryBehavior
publicprivateOnly users who have access to the private repository can edit the wiki. Other Bitbucket users and any Internet browser can access the Wiki if you publish the URL.
privateprivateOnly Bitbucket users with access can view and edit the wiki.
publicpublicAny Bitbucket user can search for the repository and then edit the Wiki. Other Bitbucket users and any Internet browser can also edit the wiki if you publish the URL.
privatepublicOnly Bitbucket users with access can view and edit the wiki.

For issue trackers, the following table illustrates how you can set an issue tracker's visibility and what behaviors the settings enable.

Issue TrackerRepositoryBehavior
publicprivateOnly users who have access to the private repository can create an issue. Other Bitbucket users and any Internet browser can view the issue tracker if you publish the URL.
privateprivateOnly Bitbucket users with access to the repository can view, create, and update issues.
publicpublicAny Bitbucket user can search for the repository and then view or create issues. Other Bitbucket users and any Internet browser can also view, create, and update issues if you publish the URL.
privatepublicOnly Bitbucket users with access to the repository can view, create, and update issues.

Regardless of whether an issue tracker is public or private, only a user with admin rights can configure a repository's issue tracker.

RELATED TOPICS

Administer a repository
Managing the Users for your Bitbucket Account
Making your Bitbucket Repository Private or Public
Making your Bitbucket Wiki Private or Public
Making your Bitbucket Issues Private or Public

15 Comments

  1. So how come my team's user ("ryppl") gets admin privileges on every fork of its repositories?

    1. The fork dialog defaults to Inherit repository user/group permissions which is why this happens. The forker (ok, there is a word) can uncheck this and the team won't get the admin access.

  2. Is there a way to see a list of authoirzed users for a specific  private repo ? Thanks

    1. Sure:

      1. Log in to Bitbucket.
      2. Go to a repository for which you have administrative rights (or create a new one).
      3. Click the repository's setttings button.
      4. Choose Access management from the navigation bar.

      The groups do not flatten out...so you have to navigate to see those members.  That is kind of a bummer. You can use the curl on the privileges Endpoint to get a list.

  3. If my repository is public, does that mean anyone can push to it?  Or is that still allowed only If I give them access?

  4. Anonymous

    > If my repository is public, does that mean anyone can push to it?

    No.

  5. So I have a Team and I want to have multiple administrators able to create repositories for this team. However, I don't want all the team members to have access to this new repository, instead I want the administrator to be able to add and remove user permissions to that repository. Is this possible?

    An even better setup would be that the Team administrator (able to create new repositories) could define repository administrators (able to add more repository users, change their permission on the repository etc) but these repository administrators would not be able to administer other repositories (or even see them if they are set up to be private).

    Is anything like this possible? 

    1. Team administrators can always add or remove users on a team's repositories.   This includes the ability to add Users to a repository that have admin rights only on an individual repository.

  6. Do these permissions are includes a bitbucket application?!

    1. Permissions for an application are granted through OAuth. Usually, that application is not modifying a repository.  For a repository, you can use deployment keys to grant read-only access to an application.

  7. Anonymous

    Dear sir,

    I have already create the account in the bit bucket and already i have installesd the source tree in our computer..I want to try add the some source code through the source tree.it's easily add in the source tree..after that when i want to view the same code through the bit bucket then it's not possible..sir please help me to access the code through bit bucket account..

    1. You can select Source from the dashboard view of your Bitbucket repository. From there you can navigate to any file you want to view. When you click on a specific file it will open in a viewable window where you can click Edit to make changes within the file. Hope that helps, and sorry for the delay in replying.

       

  8. I have administrative rights for our company Confluence software but how come I cannot see a space created by someone else but another employee can see it. Doesn't admin have rights to see all spaces within Confluence?

  9. Can we restrict that, a repository admin can share the repository only with accounts having my organization email id.? or may be to a limited list of accounts? I do not want any repository under my Team, to be shared with any personal email id.

    1. Your repository admin can restrict your repositories to only those who you choose to invite, however this is done by either group membership or by directly inviting specific users to a repository. We currently don't have the ability to limit invitations or views by domain. 

      You will have to trust your repository administrator to be judicious in their position.

      Another possibility is to create a custom groups in your team with all the users you want to have access to specific repositories and then instruct your admin's only to use the groups from the team. This will give you more control and provide the "limited list of accounts" you are seeking.

      1. Select Teams>your team.
      2. Click Manage team.
      3. Click Add group
      4. Create a group name which will be easy to determine the purpose and members of the group
      5. Select the access level and then add users to this group.
      6. Once you have added or invited the users you want on that group, you can have your repo admins use that group to add users to repositories.
        NOTE: when you create a new repository from the team all the groups in that team are given access by default. You will have to remove groups which you don't want to have access to that repository.