Issue #4828 wontfix

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

Synel Synergy avatarSynel 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 (6)

  1. Marcus Bertrand

    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

    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. Log in to comment
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.