CODEWITHSUNDEEP
azure-devops
John Little
John Little

Reputation: 12445

Azure devops, how to deny access to all but one repo to a new team

we have permission groups such as reader and contributor.

We have two teams and about 20 repos.

The new team should only have access to one of the repos.

Because all the repos have full access to the contributors permission group, and because the new team also is a member of contributors, the new group can see all repos.

I can go into each repo one by one, and search for the team, then "deny" all the rights (except it doesn't let you change the last three: read, remove others locks and rename repositoryfor some reason), but this is would take a long time.

Is there another way? I tried removing the new team from the contributors group, so that I could add the team to the repo directly, but this doesn't work - it wont let you assign any permissions to the one repo they need to the team unless they are all in the contributors group first which is not intuitive.

Any suggestions?

Upvotes: 0

Views: 1036

Answers (1)

Josh Gust
Josh Gust

Reputation: 4445

You have your answer already. Create a new group for your new team Foo-Contributors and add that team to the specific repository only. Keep in mind that any users you leave as members of the Contributors group will continue to have access to all those other repos.

If you want to be extra pragmatic you could assign that group to the Git repositories node (aka all) and assign Not set to all the permissions.

it wont let you assign any permissions to the one repo they need to the team unless they are all in the contributors group first which is not intuitive.

I'm not sure what about your setup is giving you this impression, but it should not be true.

This new group

enter image description here

Should be just as assignable to a repository as any other, and the group permissions for that repository should also be assignable.

enter image description here

Perhaps the comment on this answer will give you insight into why you see the group being "removed". Originally my comment was:

if the user being added is already a part of the groups that are added to the repo, and the permissions for the user aren't different than that of the group, then the user is removed because their "explicit" permissions are no different than their inherited permissions

In actuality I think it has more to do with the initial settings of a group added.

When a group or user is initially added to the repo, all permissions are Not set (at least in this case, b/c this group is not inheriting any permissions from any other nodes), which is effectively identical to not having that group in the permission graph for that object at all.

The linked post was mentioning that the save button needed clicking, now permission changes are auto saved line by line, so if you add the group, and then close the filter before changing the permissions, the group will be removed from the permission graph.

"add" the group but don't change permissions before X-ing the search filter enter image description here

causes the group to be removed from the object's (repo) permission graph enter image description here

Upvotes: 1

Related Questions