Reminder: Deprecation of Legacy Permissions

[#1]

The grace period for Bitbucket Cloud 'create repository' and ‘auto-assign’ permissions, deprecated when we released Project Permissions in March, is ending on October 30, 2023.

'Create repository' and 'auto-assign' permissions were originally designed to serve a flat collection of repositories with no true hierarchy or segmentation. Project permissions established a hierarchical structure of workspace > project > repository, which provides a means for permission inheritance and the ability to segment development teams.

What is changing?

After October 30, workspace admins will no longer be able to assign groups the 'create repository' permission across the entire workspace. Going forward groups may only be assigned the permission to create new repositories within the project.

Similarly, after October 30, groups can no longer be assigned new default permissions on newly created repositories. Instead, groups will inherit permissions from the project or can be assigned permissions explicitly on newly created repositories.

What action is needed?

No action is needed for now. All 'create repository' and 'auto-assign' permission assignments will continue to work on October 31 exactly the same as they do today. Your users will experience no disruption.

We are removing the ability to configure new instances of permissions but are not removing any existing configurations. All of the permissions you have assigned to your users will remain in place for now. Customers are encouraged to transition to project permissions as soon as they can but will not be forced to adjust overnight.

Existing 'create repository' and 'auto-assign' permissions can be removed from groups but they cannot modified. Once removed from a group, these permissions cannot be reapplied to a group.

How to transition to project permissions?

'Create repository' and 'auto-assign' permissions were intended to automate and scale permission assignment across a flat group of repositories but they are not fully compatible with a compartmentalized project hierarchy. Therefore, there is not a direct analog for these legacy features so adjustments are necessary.

Create Repositories

We have not removed this permission entirely but moved it under the project administration. This provides more autonomy for projects and allows more users the ability to create repositories without granting them access to other projects.

Groups of users can also now be granted the permission to create new projects in your workspace and manage that project independently of projects and repositories they should not be able to access.

Workspace admins may also create projects for each user to create or fork repositories to work on independently or with teammates.

Auto-Assign Permissions

Rather than explicitly adding new permissions automatically to every new repository upon creation, permissions are now implicitly inherited for all repositories (new and old) from the project. Permissions set on the project never need to be set for an individual repository.

Permission assignment on repositories may also be automated via the Bitbucket Cloud API.

curl --request PUT \
  --url 'https://api.bitbucket.org/2.0/repositories/{workspace}/{repo_slug}/permissions-config/groups/{group_slug}' \
  --header 'Authorization: Bearer <access_token>' \
  --header 'Accept: application/json' \
  --header 'Content-Type: application/json' \
  --data '{
  "permission": "read"
}'

When will these permissions be removed permanently?

No groups created after October 30, 2023 can be assigned either the 'create repository' or an auto-assign permission. Those options will no longer be available for newly created groups.

When an existing group - created prior to October 30 - is modified to remove either the 'create repository' or an auto-assign permission that permission will be removed permanently and cannot be reapplied. After confirming the removal of these permission configurations from a group, they will be permanently removed from that group..

Over the next 12-18 months, when a workspace is integrated with our new Unified User Management within Atlassian Admin all deprecated permissions will be removed.

[Andrew Goodman]

It's useful to be able to assign permissions at a project level - really good change.

However, as I understand it - if I grant 'Create' access at a project level, that grants the user 'Write' access to all repos in the project. This is different to the current global create permission that allows creation of repositories but doesn't grant the user access to existing repositories.

I'd love to be able to give users permission to create their own repositories in certain projects but that doesn't mean I want them to automatically get write access to every other repository in the project.

Am I understanding this correctly?

[Thiha kyaw soe]

gmail

[WoodrowShigeru]

After having made those changes I can now no longer delete branches, even though I am the owner of the repository / workspace. The option is disabled, with a tooltip "Branch deletion is disabled for this branch."

The repository permissions have an entry specifically for me, because I'm owner, with → Permission: "Admin – Can manage repository settings and users, delete repositories, and also inherits all Write permissions.", Access Level: Repository.

Does anyone else have this problem as well? Do I need to set additional permissions? Several articles point to branch permissions – but where can I manage those?

I'm using just the GUI; no API.

[WoodrowShigeru]

I've figured out: in the repository and project menus, underneath the "Branch restrictions" entry, it currently says `branch: * — Delete not allowed." And then I can untick the checkbox there.

Though, with that checkbox I can only allow everybody to delete branches or nobody. I cannot give everybody write access but only allow specific users to be able to delete.