BitBucket: Unable to apply two branch permission rules for the same branch

[JohnOknelorf]

Hello, Dear Community,

Our team uses BitBucket as our main version control service (the excellent service, btw!). We faced a little problem trying to set up the correct branch permissions in our project. What I want to do is set up the permissions for 'develop' branch so that the 'Senior Developers' group has the write access WITH the 'Rewriting branch history' access setting and the 'Middle Developers' group has the write access WITHOUT the 'Rewriting branch history' access setting.

I have to set up the two rules since they are slightly different. But the problem is that when I'm trying to apply the second rule the first one is gone (becomes re-written), and vice versa. It seems we are not allowed to set two rules for the same branch. How can I apply these rules with such a restriction?

Thank you for your time.

Regards,

John.

[Stephen Sifers]

Hello John and welcome to the Community!

We appreciate you using and enjoying our products, feedback (good and bad) is always welcome and we value your opinion. Setting permissions within Bitbucket is always a great idea as it helps to avoid incidents in the future which are sometimes accidents.

When applying permissions at a Repository and Branch level, it’s always good to ensure you check permissions from the top down. Bitbucket permissions are applied hierarchical and top level permissions may prevent users from access or seeing what they need at all. With this said, ensure that group access is configured properly, here is an example of how group access should be configured within the repository:

Once repository permissions are properly set, you need to ensure you have the branch permissions configured correctly. Here is an example of how (with your example above) the permissions for the branch should be set (it’s important to remember that Bitbucket only allows you to have a single branch permission configuration):

 

The above configuration should allow you senior developers to rewrite the history as needed along with preventing your middle developers from rewriting the history. This will also allow your senior and middle developers to both have write permissions to the repository and branches. You will need to repeat the permissions for the branch for each branch that exists.

To find out more about Bitbucket permission levels, please review 4 Levels of Bitbucket Server Permissions

I hope this helps and provide some guidance with adjusting permissions based on your users levels.

Regards,
Stephen Sifers

[JohnOknelorf]

Hello, Stephen Sifers,

Thank you very much for the detailed answer. But there is a one big "Whoops" -- it seems I described the situation poorly. I meant not the Bitbucket Server, but the Bitbucket Cloud. In branch permission window there, we have the similar structure of settings, BUT we don't have the fields in "Allow rewriting branch history" and "Allow deleting this branch" settings (only checkboxes) where we can specify the exact users/groups which are allowed to do these things (and where I can configure "except by" users/groups which you demonstrated).

Sorry for I gave a little unclear explanation. Hope this clarification makes sense.

Regards,

John.

[Stephen Sifers]

Hello John,

Thank you for the clarification of Bitbucket cloud, that does make a difference with permissions.

You are correct in that Bitbucket cloud will only allow a single named branch level permissions (of the same name), if you attempted to create a new branch level permissions with the same name it would overwrite the old.

However, a workaround to this would be to create branch permissions with a wildcard in the name. Something to be aware of is that this may create an overlapping permission scheme. Here is a screenshot of what this type of branch permission would look like:

Here is the supporting documentation for this Branch permissions | Branch permissions overlap.

I hope this information proves helpful in allowing you to control your branch level permissions with flexibility.

Regards,
Stephen Sifers

[JohnOknelorf]

Hello Stephen Sifers,

Thank you very much for your detailed answer again. Yes, this workaround seems to be working in our case.

The problem is solved, thanks! :)

Regards,

John.