Background
I'm working on implementing Agile permissions along with Code permissions for a TFS project. There will be multiple teams in this project, we currently have 3 but will grow. I am set up with Project Admin rights.
Area Permissions
At the root TFS Area Project Admins have the ability to create, delete and edit this node rights. Team members do not.
Problem
When I add my self to one of the teams groups I'm no longer able to delete items from this node even though I am a Project Admin. That means I can never be a part of the teams? This will hurt me in capacity planning amongst other areas where I work on tasks when not administrating the project.
Am I missing something? Is there a setting to allow Most Privileged or something that allows me to be a team member and still perform administration of the project?
Don't use explicit Deny permissions -- an explicit Deny overrides explicit Allows. "Not Set" is what you're looking to use -- that means "deny, unless otherwise allowed".
The problem is that "Deny" will override any other permissions. Deny always wins.
you can do 2 things
Remove ADMIN from the team group. An admin account shouldn't need to
be a member of a contributors group as admin is a superset of the
permissions given to contributors.
If for some reason you cannot remove the account from this group then
change the permissions. TFS permissions have 3 states. Allow, not set, Deny.
As the deny is causing the issue, then change the
permissions to "not set" this will still prevent members of the
contributors group from being able to manage permissions, but will
stop overriding the admin users permissions
Related
I have a TFS environment which has lots of different folders and branches and a lot of the branches have explicit permissions.
How do I reset these on mass to inherit so I can configure the permissions properly without having to go into each branch individually?
Update:
For now Clear explicit permissions only works for the selected branch , which will not either inherit to or effect any child branches.
looking to something that resets the permissions on mass as we have a lot of branches
This is not supported, sorry for any inconvenience. You could submit a user voice here: https://developercommunity.visualstudio.com/spaces/21/visual-studio-team-services.html?type=idea Our PM will kindly review any feature requests.
You could first turn on your inheritance and clear explicit with single click for each branch which have explicit permissions.
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
My TFS installation in on premise and I would like to add users to a project allowing them to create and edit work items, but not work as a developer who can create branches or check in code. Is there a default group like that?
I do not see anything in the permission list that mentions code rights.
That's exactly what the stakeholder access level is for. Access levels are different from security groups. Stakeholders don't even have the ability to see the Code tab.
I am using TFS 2015. I make one user as Readers in project settings but still the user is able to create and update work-items/bugs. So, I am confused what I need to do in order to allow a user to just view the work-items/quires/stories but not add/edit any item.
The Readers group setting does not restrict ability to edit or create work items. You can do that in area path security settings Set permissions and access for work tracking. So you may create new group (in example Disallow Access Group). Then open security setting for the root area.
Deny needed permissions
In your case you have to enable View work items in this node
If you have the user only in the Readers TFS group of the given team project, the user will not be able to able to add/edit work items.
This can happen if you have altered the group membership, so that Readers are member of the Team (the team created by default or a new team), which is default a member of Contributors. This way readers TFS Group get inherited from Contributors permissions.
Verify the Readers group has below as permissions (default)
and it is not something like below
The other possibility is your user has collection level permissions so the project permissions are inherited to allow by default.
I have assigned permissions to users on Group Level in TFS. I have a user who is assigned on more than one group and is allowed to check-in code in both groups. I want to allow user to check-in code changes in Group A but not in Group B.
I will be thankful to you if you can guide me how i can do this.
Regards,
No, we cannot achieve that.
In general you should try to avoid having users in multiple groups as in TFS deny always wins.
That means if you set check in as Deny for Group B, then all the users in Group B will not be able to check in changes even though the user in other groups have the Allow permission.
Permissions
It combines the permissions from all the users groups.
If the user is denied access to anything they still can't access it
even if they are given access to it elsewhere.
If the user is given access to something in any group they will have
access to it (unless of course something else denies them).
If there's no explicit allow or deny in any of the users groups, they
will be denied access.
I think that people in GroupA work in part of source control and GropB in another. If so You have to enable check-in policies in both groups and instead configure source countrol foder or branch security policies in order to anable or not chech-in or even other features on any group.
To do that:
Go in source control explorer
Rigth click on folder or branch: Advanced->Security
Enjoy!
If a user has access to multiple security groups, does TFS take the highest level group, or the lowest level group for access rights?
For example, if user John, belongs to the Read Group (can only read the source control but not edit) and then is added to the Developer Group (can read and edit source control) which group does TFS recognize?
Since he belongs to both groups can he still only Read since that is the lowest level or can he now edit since he is also part of the Developer Group and that is the highest level?
Permissions
It combines the permissions from all the users groups.
If the user is denied access to anything they still can't access it even if they are given access to it elsewhere.
If the user is given access to something in any group they will have access to it (unless of course something else denies them).
If there's no explicit allow or deny in any of the users groups, they will be denied access.
Access Levels
Access levels are done separately from group permissions - access can be set to limited, standard or full in the tfs 2012 admin area.
For TFS 2010 the only group that acted a bit weirdly was the work item only group, which afaik acted as a explicit deny on everything but editing your own work items. This functionality is replaced with access levels in tfs 2012.