Upcoming repository creation permissions changes - can't replicate my existing process with it?

Question

I have read the post https://community.atlassian.com/t5/Bitbucket-articles/Taking-Bitbucket-permission-management-to-the-next-level/ba-p/2264892

I am confused about how to replicate my current setup once these changes have been implemented:

Currently

I have one workspace and one project. All 4 users belong to the ‘developers’ group which has workspace permissions to create repositories. So any user can create a repo.

For some repos all developers have write access to the repo, for others only one of the developers has write access, the rest are read only. Currently this latter is easily achieved by setting the developer group permission at the repo level to 'read'

Once the changes are rolled out

I think we have to give the developer group 'create' permission at the project level so that all 4 users can create repos? But that automatically gives all 4 users write permission on all repos in the project? And the repo level permissions don't subtract access, they only add. So there is no way under this system to now have repos where there is only 1 user with write access?

Patrik S · Answer

Hello @cerevance_jpowell ,

Thank you for your feedback, and we understand your concerns about the deprecation of that option in User groups. While it may not be ideal for every use case, the goal of project permissions is to maintain project integrity and autonomy. Keeping that in mind, I would like to suggest a couple of workarounds that might help you on providing the ability for users to create repositories without them inheriting write access:

* Using a script or a tool with a workspace access token that a user can use to create a repository using the API endpoint Create a Repository. The token will have access to create the repo, but the user will not be an admin of that repo or any other repo. This way, they will have the same permissions on the new repo as they do on other repos.
*  Another option you could consider is creating a personal project for each user, allowing them to create repos within their own space. They can manage these repos independently or transfer them to other projects when needed.
* Alternatively, if you prefer a less rigid structure within the Workspace-Project-Repository hierarchy, you can assign the “Create Project” permission to these user groups instead of the more generic “Create Repo” permission at the workspace level. This approach enables those users to create new repositories in separate projects without granting them elevated permissions in projects where they don't have the authorization to create repos.

While these suggestions may not directly implement repository-level permissions to 'deny' access previously granted by the project permission, they can provide alternative ways to achieve the desired level of control and autonomy for your team members.

We appreciate your feedback and will continue to improve our features based on user input.

Thank you, @cerevance_jpowell !

Patrik S

cerevance_jpowell · Answer

Thanks for the info. I don't see my use as much of an edge case - surely allowing a group of people to all create their own repos can't be uncommon? But these now have to be writeable by the whole group. And the only way to fix this is to create a project for every single repo? That seems fundamentally broken to me.

It seems to me the obvious solution is to enable the repository level permissions to 'deny' access previously granted by the project permission.

Patrik S · Answer

Hello @cerevance_jpowell and welcome to the Community!

The new "Create" on projects also includes all the permissions of "Write". When you assign the "Create" permission to a User/Group on a project, this will grant the user/group not only the ability to create repositories, but also grant "Write" permissions to all repositories within that project due to permission inheritance.

As a result of this change, it is no longer possible to assign the "Create" permission to all users without also granting them write access to the repo.

A potential workaround for this would be to create a project for each repo, allowing you to give individual users permission to create repos. However, this may defeat the purpose of using projects in the first place.

Using a strict inheritance model does not allow for every edge case, unfortunately, but it does allow for a much more simple and predictable security model.

Thank you, @cerevance_jpowell !

Patrik S