Taking Bitbucket permission management to the next level

[#1]

We have enabled the feature flag for 100% of all workspaces in Bitbucket. Everyone should have access to set project permissions. 

• Blog Post
• Support Documentation

We're excited to announce the upcoming addition of project permissions and permission inheritance to Bitbucket Cloud. These much anticipated changes will improve permission management as we continue to build a more enterprise-ready Bitbucket Cloud experience. Similar to project settings that we released last year, you will soon be able to configure group and user permissions for an entire project.

The project permissions model was intentionally copied from our Bitbucket Server and Data Center product to ensure a seamless experience for our customers migrating to the cloud while also causing minimal disruption for our current cloud customers.

There are quite few changes included in this release that impact how permissions are managed, but it is important to note that nothing should break in your current configuration and your bill will not change. We anticipate rolling out these changes next month.

Project Permissions

Very soon you be able to configure repository permissions for your projects. With this release, admins can grant access to all repositories, old and new, within a project without having to manage each repository individually. Not only does this save significant time for administration, but also ensures that all repositories share consistent permissions and comply with that project's standards.

Projects will have 4 hierarchical levels of permissions: Admin, Create, Write, Read. Each permission in the hierarchy includes all permissions below it. E.g. Admin includes Create and Create includes Write.

• Admin - grants full administrative control of the project and the repositories within. Admins can make any changes to project or repositories settings, including all permissions. For existing projects, the current workspace admins will assume the role of project admin but they can now delegate this responsibility to others.

• Create - grants permission to allow users to create repositories within the project and provides write access to all repositories in that project. 

• Write - grants permission to allow users to commit content on any repositories in the project.

• Read - grants permissions providing users with exactly that, only the ability to read the content within any repositories.

The introduction of project permissions will make projects much more autonomous, enabling admins to better manage repositories at scale and also create more compartmentalization within the workspace for teams to work independently.

Permission Inheritance

To enable project permissions for Bitbucket Cloud we are also introducing permission inheritance. Permission inheritance allows permissions configured within a project to apply to all repositories in that project. Permission inheritance will also give workspace admins more control of the workspace.

To date, Bitbucket Cloud has relied on explicit permissions to grant users and groups Read, Write, or Admin (R,W,A) permission configured in each individual repository’s settings. Only users or groups listed in the repository Users and Groups settings have access to that repository today. Repositories can soon have permissions explicitly configured per repository but also inherit permissions from the containing project. Permissions set within the project or the workspace implicitly apply on the repository and cannot be modified within the repository.

Admin Changes

None of your existing repository permissions will be affected by the release of project permissions and permission inheritance. Everything will continue to function exactly as it does today for end users with no disruption. However, the addition of this new functionality will necessitate some changes in how workspace admins approach permissions in Bitbucket Cloud.

The most impactful change will be that workspace admins have implicit access to everything in the workspace due to permission inheritance. Workspace admins will inherit project admin permissions and repository admin permissions. This ensures that workspace admins retain full control of all workspace content regardless of whether they have explicit access configured for projects and repositories. Workspace admins will rightfully have full control of the workspace but can now delegate project control to project admins, reducing the need for more than a few workspace admins.

To streamline the admin experience we are also removing the Users on plan page and consolidating all of this page's functionality on the User directory. Rather than having two separate lists of workspace users you can now view everything from the User directory. Simply choose the dropdown to filter on Users on plan.

Group Changes

The other changes impact Group settings within the workspace. Today, all workspace permissions are configured for each group within workspace settings. This will not change immediately, but the settings available to set across these groups will change.

• In order to make projects autonomous, we are deprecating the ability to grant permission to create repositories within a workspace. Users will no longer be able to create repositories in any project across the workspace; instead, project admins will control which users or groups can create repositories in their respective projects.

• Because we deprecating the permission to create repositories globally within the workspace, we are introducing a new permission allowing groups to create new projects in the workspace. Previously, only workspace admins were allowed to create new projects. Users who can create projects can then create any repositories within the new project. Workspace admins can now open up the creation of projects to all, none, or just a few users. The creation of projects can be tightly controlled or fully self-service.

• Finally, we are deprecating the ability to configure the automatic assignment of permissions to groups for all new repositories created. This feature was implemented long ago as an alternative mechanism for configuring repository permissions at scale and is being phased out by project permission inheritance. All new repositories will inherit the permissions set at the project level and not require explicit permissions to be configured unless it varies from the project.

Grace Period

To create the least amount of disruption, we are deprecating these features on group settings, but we won’t be removing them overnight. Rather, we will have a six-month grace period starting the day of the general release of project permissions to ensure that all customers have ample time to adjust to changes introduced for project permissions and permission inheritance. At the end of the grace period, we will remove the Create repositories permission and the ability to Automatically assign permissions for new repositories from within group settings.

With the implementation of permissions and permission inheritance within projects, you can now have more and better control over how you administer Bitbucket Cloud from your workspace to the code that gets merged. Knowing that we’ve received positive feedback about this permission model in Bitbucket Server and Data Center helped us to confidently put this permission model in place to improve the administration experience across Bitbucket Cloud.

[Chris Hall]

What is "very soon"? Can it be measured in days or is it closer to "real soon now"?

[Raul Botello]

This functionality will be abiavalable for Bitbucket Cloud Standar version? 

[Randall Eike]

Better late than never!

[Kiril Jurbinsky]

I do not understand how it wasn't available until now. it was always available on the server, so after forcing everyone to move to the cloud, now you announcing "Taking Bitbucket permission management to the next level"

[Tim Chaffin]

This is like... a bare necessity feature. I'm not sure how Bitbucket made it past MVP without this. But, thankful for the feature nonetheless.

When will be able to apply branch restriction patterns, project level secrets, default tasks, default reviewers, and other repository level settings, we manually repeat every time we create a new repo under a project?

[Curtis]

While it seems like an obvious feature, and something that has existed in Server/Data Center for ages, we have to remember the history behind Bitbucket Cloud, and that it wasn't Atlassian's creation. Atlassian purchased Bitbucket, to have a Cloud offering similar to their hosted option Stash. They then renamed Stash to Bitbucket, to match their new Cloud offering.

[Quan Nong]

Long time in coming.. trying to manage repo permissions from different projects was so bad 

[Ulrich Kuhnhardt _IzymesCo_]

Is there a preview of the updated Bitbucket Cloud REST API available for developers?

As a connect app vendor - how can we best count all members of the workspace that currently have 'Collaborator' status?

When the collaborator role is deprecated how do we count active users where the result is the same count as Bitbucket's "Users on plan"?

We used this query in the past: `https://api.bitbucket.org/2.0/workspaces/${workspaceId}/members?q=permission="collaborator"` which worked pretty well.

Thanks for your help @Patrick Wolf

[Jin Kang]

When is this feature slated to release? We have a huge need for this now more than ever. If there's an opportunity for early access, would love to participate in that. Thank you!

[REKHA.DHARWAL]

When is this feature rolling out? Please keep us updated.

[brent.mills]

It can't come soon enough!  Hopefully, this thread will get updated when available and we'll all get notified.

[Elderama]

To busy virtue signalling with "celebrate pride every day" rainbow icons to release basic functionality like this that everyones been waiting for.

[Christoffer Berg Boisen]

I just came here to say this feature generates little/no value to us, and I'm doing so to balance out the somewhat critical "why is this only coming out now?" type comments.

But I guess we don't have hundreds of repositories where we frequently make changes to permissions, so it's a bit of convenience but not really changing much for us.

[ngg]

We currently have a group that are only granting the "Create repository" permission without giving Write access to any existing repository. In the new system, how can we achieve this if the Create permission will imply Write?

[Murthy Mokkapati {Appfire}]

How about pipeline runners? Can they be restricted to be used at Project level?

[Bret Westenskow]

This is great to see! I would also like to see more granular permissions around Pipelines. Right now you can restrict certain pipeline environments to admins. We need to be able to allow others (but not everyone) that aren't admins.

[mgnavarrete]

Is there any news about when this feature is going to be released? In order to set project permissions through API rest, will it be able to do it with OAuth? or is it will be mandatory to use app password as it is with repository group permissions?

[Levente Bedő]

This is great news!

There are many Atlassian cloud features, many of us expect to exist and is not available.

Based on careful considerations taken and communicated I hope this team will work on more "past due" features.

@Patrick Wolf - Atlassian 

[Francisco Aguiar]

So, very soon is more than 2 months right?

[Vadim Lutsevich]

Looks like it is still not deployed. At least I can't see it in all of my workspaces.

[mgnavarrete]

I don't know if it has been publish in other post, but apparently this "project permission feature" is working already, but it is only in the UI but not implemented through the API for now at least.

[tashoma abara315]

tashomaabara315@gmail.com

[Cameron Gocke]

Just FYI for everyone else here waiting, this post states that everyone should see this in their workspaces before the end of April: Project Permissions are now available in Bitbucket Cloud - Bitbucket

[Jason Prinsen]

Very excited for this. Not available yet as of 4/18/2023

[Sébastien Morin]

It looks like I have it available for my organization, but there doesn't seem to be a way to remove permissions at the repository level, only add permissions.

So let's say I have 10 repos in one project and I need read/write access to all but one of the repos (which would be read-only) to a certain user group, as the project permissions are currently designed and implemented I have to either:

• Create a different project for that 1 repo.
• Move the project permissions back to repo permissions
• Give Read access at the project level and give write access to the 9/10 of the repos that should be able to be read

I would've expected to give Read/Write access to the whole project and just Read to the single project that I do not want to be Writable, but that will not work, users of the group will end up having the project level Read/Write access to that repo.

It has been a while since I've used the Project Permissions in Bitbucket Server, but I don't remember this being an issue on that product.