Why can't I see a repository forked from my team's private repository?

[mvrkljan]

I've sent an invitation to someone who will be working as a contributor on a private repository that I've created on a team profile. The person created a profile and is in a group with 'read' permission, and he managed to fork the repository with no problem.

However, in the team's repository page his fork is not counted in the total number of forks, his fork is not listed in the forks list and when I access his forked repository through the URL I can only see Issues and Wiki tabs, no Source, Commits or anything else.

He says that his email was confirmed successfully - my first thought was that his primary email might've been unconfirmed.

I've tried changing the access rights for his group since someone with different access rights managed to fork my repository with no problems (and I can see his fork), but that didn't make any difference.

Does anyone know what could be the problem?

Thanks!

EDIT:

A bit more information;

We have a team repo REPO, the Administrators group, Developers group and Outsourcers group in that team. Outsourcers have read access to team's repos. The member in question is in the Outsourcers group. He created a fork, and I (the team administrator) can't see his fork. He didn't de-select the inherit rights checkbox. Another member who is in the Developers group created a fork of his own and I can see that one. I've tried switching the problematic member to Developers group but his fork is still not visible.

[aMarcus · Accepted solution]

When a user forks code on Bitbucket, they have the option to inherit permissions from the paretn respoitory. This inheritance only carries over groups and permissions that the user who is performing the fork is a member of. For example, say you have 3 groups, Admins, Devs and Contractors. All three groups are added to an example repository (repoA). When a user who is only in the Contractors group forks the repository, only the Contractors group can be inherited to the fork or repoA.

This means that even Admins won't be added to the fork and subsequently won't be able to see it or interact with it. We don't provide any way to force inheritance of permissions to forks to any users. This is by design.

The way around this would be for the owner/manager of a repository to fork the repos intended for Contractors into the same team account and restrict access to only the appropriate group. This way, the Contractors will be able to interact with this repository as they need to, while other devs and admins will be able to look in on it and do whatever is needed.

Of course, things can always be reviewed and changed in the future. I have opened https://bitbucket.org/site/master/issue/4434/add-an-option-to-allow-the-original-owner to discuss this as a possible future feature. There is no guarantee that we will impliment it, but please feel free to comment there to help us understand your use case.

Original response:

When forking a repository, the user can de-select to inherit permissions from the team repository. This effectively limits the view+ access to only the user who made the fork. This is by design as user accounts do not inherit the team's account limits. If it enforced this, all members of a team would also need to have a paid account that matched the number of people who needed access to that fork.

[mvrkljan]

Hey Marcus, thanks for your answer. I've checked with him, and he didn't de-select inherited permissions. He forked the repo with default settings and there are less than 4 of us who need to be able to access that fork.

I've edited my question with additional information.

[aMarcus]

Can you open a support request with the specific details so I can take a look and possibly explain/investigate further. In short, to be clear, your account doesn't and won't retain any ownership of forks when made. This means the user is free to cut you completely off from that fork if they see fit.

[mvrkljan]

I don't have a product licence to open a support request, I'm using Bitbucket as a free service. But in short, what's confusing me is that I have two members in my team, they both forked a single team's repo, leaving all the default checkboxes checked (I recieved email about both actions and access rights for both forks) but when I'm logged in with my account (team admin) I can see only one fork from one member.

Update: The other member had to specifically add me to his forked repo through Access Management repo setting and give me read access to see his repo. What's confusing me is that the first member didn't have to do this?

[aMarcus]

I don't have a product licence to open a support request

The support.atlassian.com system is 100% free to create an account, use the sign-up link to create your free account. We answer all Bitbucket account support questions whether they are paid accounts or not. Simply select the "Skip" link at the bottom if you don't have an SEN or hosted URL. I'd be happy to take a closer look at your repositories if you'd open a support request. It'll be much easier to explain given the context of the issue. The only way (that I can see) there could be a difference here is if the user removed your acces immediately after they forked the repo, or if they unchecked the inherit fork permissions.

[mvrkljan]

I missed the 'Skip Validation' link when creating an issue, my mistake! Issue created. Thanks!

[Ryan Schumacher]

Martin, why isn't this seen as a bug. Technically if a project is private then wouldn't it seem like any forks associated to this project should be forced to inherit certain permissions (ie administrators can see fork)? Where would I go to submit this as a request/bug?

[aMarcus]

Bitbucket's official public issue tracker is at https://bitbucket.org/site/master/issues/new. However, this feature request is already open at https://bitbucket.org/site/master/issue/4434/add-an-option-to-allow-the-original-owner. We impliment all feature requests based on interest from the community and our current road map.