Atlassian Team members are employees working across the company in a wide variety of roles.
April 18, 2023 edited
Yes @Tim Chaffin and @Sébastien Morin that is by design and how permissions work in Bitbucket Server and Data Center. The higher privilege takes precedence whenever there is more than one permission configured.
Assume I have a group with Write access on a project. If I assign a user in that group with Read access on the project or a repo that user will still have Write access from the group based on the order of precedence.
There are a few reasons that this is the case.
If this were not true then it would be possible for repository admins to remove permissions from project admins and lock admins out of repositories. This is not a good security practice.
Creating exceptions to higher level security configuration creates a much more complex security model and violates KISS principle. Looking at the permissions set on the project becomes meaningless if none of the permissions configured on the project are guaranteed to be applied on the repositories. It would be possible to have no project permissions in effect for each repository.
Trying to create exceptions to work around 1 and 2 increases the complexity of the security model by an order of magnitude.
Using a strict inheritance model does not allow for every edge case, unfortunately, but it does allow for a much more simple and predictable security model.
Hello all! I'm still not able to see in on any of the projects on my organization, I just tried creating a new project but still the "Project Permissions" tab isn't there. Do we need to enable anything at organization level?
@Patrick Wolf - Atlassian - any more details on the branch permissions and merge checks? Exciting! I have not seen those features announced anywhere else? Anymore information or documentation on this? Can I bribe you for early access? ;)
Atlassian Team members are employees working across the company in a wide variety of roles.
May 2, 2023 edited
@Tim Chaffin - you can follow/vote on this ticket for Project Level variables and secrets. It's definitely something we have planned, but we're currently running at full capacity with a few other projects and don't expect to get space for Project Level Variables etc until later in 2023.
The permission levels mentioned above seem to be different than what was actually implemented.
Above:
Read - grants permissions providing users with exactly that, only the ability to read the content within any repositories.
Actual:
Read - Can clone, browse and fork any repository withing the project. Can create and contribute to pull requests targeting any of these repositories.
We have teams that want people to have true Read only access and not have the ability to create PR's. Is the documentation above wrong or was it implemented differently than anticipated?
A developer couldn't access a repo for a while even though there was repo level permission. I had to add the project level permission and then after a few hours the project was visible. It might just be how he was accessing the repo.. Ie through project list.
FYI, for anyone interested, there are also limitations in how these permissions can be used to affect tags, which is different from how it worked previously with Bitbucket Server. There is a feature that was opened on my behalf, but which doesn't have much attention so far, which I think is going to be a problem for many of us.
Make it even better by separating repository administration permissions from pipeline management as current model is limited/broken, here is why
You cannot segregate a repository Pipeline management from Users and Groups access management.
If you want to provide a DevOps/SRE/Developer access to set up and update the pipeline, you must also give them Administrator-level access within that repository, which allows them to do about everything, including providing access to other users.
Please make the Pipeline permissions separate from the Repository administration, including the API Access Token permissions, which is broken in the same way.
Could you explain what will happen with user permissions to creating repositories if we don't provide any Create permissions under particular project? They will not able to create new repos anymore?
It seems with these changes, in order for someone to create a repo in a project, they need to be an admin. Before we had a group that could create repos, but not projects across the workspace. Now, the only way to do that is allow those users to create projects, so that they can create repos. This is a not working for us. Please do not deprecate the "Create repos" option. That way I can allow certain users to have repo management across the workspace, but not the ability to create project.
I do like that repos can only be created within a defined project. Ideally, Workspace admin will created the project, and a subgroup will automatically be added but the can only create repos in the project.
As an Development Manager, my workaround is to have a project where anyone can create a repo (a new repo wild west). Then once a week someone like me will come along and move the repos to the correct projects.
That way anyone can make a repo initially but someone who is authorized is part of the process to get them where they need to be so they inherit the correct project permissions.
@Jason Prinsen this still does not fix the issue with not having a DevOps/SRE/Developer being able to manage a pipeline WITHOUT also being able to fully manage the repository other aspects.
48 comments