1. Bitbucket Website
  2. Public Issue Tracker
  3. master

Issues

Issue #4828 duplicate

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

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 (15)

  1. Marcus Bertrand [Atlassian] 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 [Atlassian] 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. hrj

    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 Matt Barrett 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. Josh Stuart

    +1

    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.

  10. 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...

  11. Log in to comment