Is there a simple way to manage security at a project level and override it at a repo level.
For example, we have a project called UPN and it has 100 repositories in it. At a project level we setup branch security to say
Branch Name : Master
Deletion : (BLANK)
Rewrite History : (BLANK)
Changes w/o Pull Request : (BLANK)
All Changes: our-developer-group
This is a huge time saver as we don't have to manage security for each repo. However we commonly hit scenarios where we might want a repository to temporarily bend the rules. For example we might want to restrict the changes for repo-x to a smaller group during a certain period or we might want to enable Rewrite history to allow a one time rebase.
So in repo-x I added another branch permission on Master
Branch Name : Master
Deletion : (BLANK)
Rewrite History : (BLANK)
Changes w/o Pull Request : (BLANK)
All Changes: our-special-user-group
It looks like the security there is additive instead of overriding. Is there a means to override security without having to move the repo and or changing it at the entire project level?
This is old, but I had to struggle with it this evening.
It is additive, but the only way to loosen permissions (at least with our corporate bitbucket server) was to add a new permission to the repository that copied the project branch permission, but had an exception for the users you wanted to allow the action to.
Non-intuitive, but it worked.
nah its crazy, this should totally be reviewed and implemented properly. repo owners should totally be able to override project permissions if they choose to
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It worked!
I had to enable branch deletion in order to allow branch creation!
I had an empty repository and we only allow merge commits in the master branch, that means that you cannot push an initial commit to the master as there is no master.
In project settings it had rewriting history and deletion disallowed. I had to create a new restriction that had to check both allowing rewriting AND deletion in order to push the master branch.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Tim,
Thanks for reaching out here.
There is no known way to override the project level branch permission in the repository level branch permission. When the branch permission is added at the project level, it is applied to the repository level also.
You can find more details for this at BSERV-3508.
Kind Regards,
Victor - Application Support Engineer.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
To add to what @VICTOR-OSEGHALE said:
It looks like the security there is additive instead of overriding.
That's right, the permission model in Bitbucket Server is additive, so the best approach to take is to make your permissions as restrictive as possible at the Project level and relax it at the Repository level.
we might want to restrict the changes for repo-x to a smaller group during a certain period
This isn't possible with the additive permission system
we might want to enable Rewrite history to allow a one time rebase.
With the additive permission model, the most permissive set is what gets applied, so if history rewriting is disabled at the project level for a given branch permission and a branch permission (targeting the same branch/pattern) with rewriting enabled is present at the repository level, then that is what's applied. The inverse is then of course also true, which is why starting out with the more restrictive set at the top level is required for limiting access.
Regards,
John van der Loo
Developer, Bitbucket Server
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.