CODEWITHSUNDEEP
azure-devopsazure-security
alexmage
alexmage

Reputation: 115

AzureDevops branch permissions settings

I have checked the docs from Microsoft for AzureDevops and I understand how to manage permissions for a branch.

What I would like to know is if a user is automatically added with Edit Policies permission to Allow as he creates the branch (assuming a normal user not admin, and he's not inheriting this permission) ?

If the answer to the above question is yes, then is there any case when a second user could be added to the list of branch permissions automatically ? without an administrator adding it explicitly ? I couldn't find this in the docs anywhere.

*picture from msdn

branch permissions editing

Upvotes: 0

Views: 6858

Answers (1)

PatrickLu-MSFT
PatrickLu-MSFT

Reputation: 51073

Yes, for each branch's permission setting, you could directly manage that user's or create a group then add that consultancy in the group, manage the group's permission.

In other words, without adding it explicitly, the user B could also be added to a group. You just need to make sure that you are not part of any groups that have the complete privilege Denied.

In Azure DevOps, Deny trumps Allow.

Unless you're a member of the Project Collection Administrators group on your organization, membership in a group that explicitly Denies any permission will deny your permission, even if you are in another group that explicitly Allows you the permission and even if you as an individual user are granted Allow on that permission.

We usually add developer to Contributors.

For the Inheritance part, you could turn on your inheritance and clear explicit with single click for each branch which have explicit permissions.

enter image description here

enter image description here

After this, Contributors Group in other branches will totally inherit the permissions set by root path of your repo/workspace. For example, if root path are Allow, your branches should be Allow(inherited), if it's Deny, your branches should be Deny(inherited).

If a permission isn't directly allowed or denied for a user, then it may be inherited in two ways.

  • Users inherit permissions from the groups to which they belong. When

    a permission is allowed for a user directly or through membership in

    a group that has that permission, and it is denied, either directly

    or through group membership, the permission is denied.

    Members of Project Collection Administrators or **Team Foundation

    Administrators** retain any allowed permissions, even if they belong to

    other groups that deny those permissions.

  • Object-level permissions that are assigned for nodes of a hierarchy -

    areas, iterations, version control folders, work item query folders -

    are inherited down the hierarchy. That is, a user's permissions that

    are set at area-1 are inherited by area-1/sub-area-1, if the same

    permission is not explicitly allowed or denied for area-1/sub-area-1.

    If a permission is set explicitly for an object, like

    area-1/sub-area-1, then the parent node is not inherited, regardless

    of whether it is denied or allowed. If it's not set, then the

    permissions for that node are inherited from the closest ancestor

    that has the permission explicitly set.

More details please take a look at our official tutorial here: Inheritance and security groups

Upvotes: 1

Related Questions