How do project level branch restrictions and repository level branch restrictions interact?

[Jay Seletz]

I have a large number of repos in the same project with identical branch restrictions setup (from before the project level settings were added).  I've now added the same restrictions at the project level.   So at the repo level, I see both the inherited branch restrictions and the existing ones.

If I modify a project level setting for a branch type or pattern, how does this affect (or not affect) the branch permission at the repo level with the same branch type/pattern - which rule wins, or are they combined, or what?

The main case I'm interested in is temporarily removing a restriction for the project to allow a normally disallowed action (like deleting a branch).  Currently both project and repo level settings do not allow deleting a branch type.  If I modify the project setting to allow this, will the repo level setting override and disallow, or will the project level setting override the repo and allow it?

[Patrik S]

Hello @Jay Seletz and thank you for reaching out to Community!

The project-level branch restrictions are no different than repository branch restrictions when it comes to enforcement and administration. When you access a repository branch restriction page, you will also see the branch restrictions inherited from the project and they will be applied in the same way, respecting the permission priority outlined in the following documentation : 

• https://support.atlassian.com/bitbucket-cloud/docs/configure-a-projects-branch-restrictions/

One of the overlapping rules is that 

• DENY overrides ALLOW

meaning that for your use case, if you have a project branch restriction that allows deleting a given branch, but the repo-level has a branch restriction that denies deleting that same branch, you won't be able to delete the branch as the repo-level "DENY" rule will override the project-level "ALLOW" rule.

Hope that helps to clarify your questions!

Thank you, @Jay Seletz !

Patrik S

[Jay Seletz]

Thanks Patrik, I read that doc, and for me it wasn't clear, but it appears that there is no "hierarchy".  So project level rules act the same as if they were additional repo level rules, and then "conflicts" and "merges" are handled the same way as with multiple repo level rules.  Can you clarify what these two lines from the doc actually mean?

• Anything can override non-branch specific access
• Highest extra value wins if there's a conflict (should never interfere with other rules)

[Patrik S]

Hello @Jay Seletz ,

You're correct, the project-level restrictions are treated just like additional repository-level restrictions, where the same repo restrictions overlap logic applies.

Following are more details about those two particular rules : 

• Anything can override non-branch specific access
  
  This means that any branch restriction overrides implicit permissions on a repository granted via group membership or directly on the repository. For example, if a user has ‘admin’ or ‘write’ access to a repository via a user group, they may still be restricted from pushing to or merging Pull Requests against a certain branch if a branch restriction exists that matches it.
• Highest extra value wins if there's a conflict (should never interfere with other rules)
  This applies to every branch restriction that has a number value associated, such as minimum number of approvals, number of successful builds, etc. If there's an overlap between multiple branch restrictions, the one with the highest configured value will take precedence.

I'm also raising a request to our internal team to include those details in the branch restrictions page in order to give more clarity on what each of those rules means.

Thank you, @Jay Seletz !

Patrik S