Team admins don't have read access to forks of private repos

Issue #4828 duplicate
Synel Synergy created an issue

I have a repository under a team account. It is marked private, and no public forks. In the access management of the repository, I have granted Admin access to the team's Administrators group, and Read access to the team's Members group.

When a Member of the team forks the repository, I expect that all Administrators of the team have at least Read access to the fork, so they can review progress and accept pull requests. But apparently, the only one that can view the fork is the owner of the repository. Other team administrators do not have Read access on the fork, so they cannot participate in administrating the repository by accepting pull requests.

Comments (22)

  1. Marcus Bertrand staff

    We don't force inheritance of forks for teams or anyone else. If you are looking for far stricter control for your Team, consider our behind the firewall product Stash. It offers many user controls geared towards enterprise level features.

  2. Synel Synergy reporter

    I don't really want to go behind the firewall, the whole point of bitbucket is that our team can be spread out around the world and we don't have to maintain our own git servers. I just need a way to make sure that forks of our repos are visible to administrators of that repo. Is that really too much to ask?

  3. Éric Araujo

    FTR we’ve had similar annoyances: when a team member forks a private repo, the plan for the fork is limited by the user’s plan, not the team plan, which gives the impression that team workflows are not fully thought-out. (Due to the lack of easy account switching à la Google apps, people have just one account for work and non-work repos, which I think is how most people do it.)

  4. Arialdo Martini

    I also am interested in the behavior described by Éric Araujo.

    I'm a member of a team (with a billed team plan). Using my own (free) account (which is part of the team), I forked one of my Team's private repository.

    Not all my teammates (but just 5 of them) can access my repo, because the plan of my fork is limited by my own plan, not my team's one.

    This is a pretty big impediment in adopting the Forking Workflow. It seems that the only possibility is forking the Team's repository with the Team's account itself, which is pretty annoying.

    Is there a best practice I could follow to avoid this limitation? Cheers

  5. Sébastien GAUTRIN

    I support Éric's and Arialdo's point, we have the same problem, although not yet as critical for now, as we are a team of 5, and each of us use a Bitbucket account just for the company projects. The recent change displaying PRs contents when you have visibility on the target repository even though you have no visibility on the source repository helps, though it's still limiting.

    We could of course give developers write permission in the team account, and have them create developer forks withing the team account, but that would quickly bloat the team account, make it harder to find "reference" repositories, and give too many permissions to developers on the team account.

    What would solve all our problems, as well as Éric's and Arialdo's I presume, would be a "simple" change in the billing computation: access given to a team member on a repository that is a fork of that team's repository should not be counted towards the access limit (at the very least this should be the case when access is granted through the use of the team's groups, e.g. giving read access on the fork to the group team:developers; ideally we should be able to simply inherit permissions from team repository when forking without to have to worry about hitting the limit on developer accounts).

  6. Matt Barrett

    @Marcus Bertrand is this really a duplicate of #4056? That issue is with regard to access control while this issue has more to do with better utilizing the "Forking Workflow" with private team repositories and subsequent pull-requests from private user repos. I can see how they might be related but just wanted to make sure that this issue is addressed. As it stands currently, it's very hard to work with pull-requests from forks of private repos and larger teams.

  7. Harshad

    Agree with @Matt Barrett

    This issue is only about read access. I would like to atleast see the forks from my team members. This could be to simply know what they are working on.

    Whereas #4056 is about admin access. Related sure; duplicate nope!

  8. Richard Saunders

    I agree with @mattbarrett and @hrj . This is not a duplicate ticket and this ticket should be considered separately. It is a genuine request that I would like to see too which is to give the admin of the main repo 'read access' to the forked repo. This maybe could be done by creating the read permission on the forked repo for the admin at the time of forking automatically (or giving the forking user the choice of permission level, defaulted to read). I'm ok with the forking user having the ability to then go in and remove that permission later (i.e. not enforcing the permission)

  9. ideasid NA

    I agree too. We are also stuck at the same problem. How come, yet the solution is not developed ?

  10. Josh Stuart


    This is expected behaviour because how else can I checkout a pull request and verify everything runs correctly? I understand CI / webhooks etc etc, but for a manual process I can't, unless everyone has an individual paid account to allow enough permissions? This is craziness.

    FYI, github private forks allow team access.

  11. Even André Fiskvik

    +1 this is a tremendous issue for integration with other CI systems and it's almost enough to push my org to push everything over to GitHub which is working fine for all our other projects...

  12. Doug Linley

    It's June, 2016 and Atlassian still seems adamant that this isn't an issue. In Github I can more easily have my team's repos shared so that I can pull them down once a PR is submitted. I don't understand why bitbucket won't address this, as it seems to be a real hole in the workflow for many teams.

  13. Rob Quist

    Up again, running into the same issues here. If you want to get users to pay for your software do that another way and not like this. This is simply annoying.

    I'm thinking of moving to Github purely because of this.

  14. Vineet Reynolds L P

    Is there really any workaround for this issue? I just can't see how the Forking Workflow is achievable in BitBucket for private repositories.

    Forks of team repositories by team members should be visible to team admins, if not all team members. Without this, team members now have to upgrade their plans to allow access to the Developer group, when more than 5 developers are involved. When the team is already on a plan, this is just ridiculous to have this requirement to have individual accounts also upgrade their plans.

  15. Leevi Graham

    +1… As an admin I want to be able to see forks so I can review progress or even pull directly from the repo.

  16. Josh Hill

    Bitbucket doesn't support for the forking workflow like Github does.

    Forks of team repositories, by individual team members, are next to useless when compared to Github. Permissions have to be added, user limits apply when adding permissions, if adding >5 each team member must upgrade their plan (wtf), and when user is removed from team the fork remains.

    An ugly workaround.

    Create project called forks. Fork repository and select team as owner and forks as project. Name repository [fork owner]-[repo name]. Permissions will be as expected.

  17. Sandra

    having the same issue here. when I forked, I could add one of the team's groups (less than 5 members), but since I used a separate work account I can't add the rest of the team.

    I am currently using a workaround using my personal account, two origins and using the bonus member access I got from getting people to sign up years ago to get around this. E.g. I've created a new repo in both work+personal account, set upstream to both, given access as many of my team members as I can on both accounts.

    Another way to possibly get around this would be to share a bb user account and give it ad-hoc access to the relevant repos. that way, it only counts as 1 user, but the account itself can be used by multiple members of the team - though I imagine this has both security and legal implications (probably against the terms etc)

  18. Log in to comment