TFS2015 u2. I'm editing a release definition, assigning approvers for an environment.
I have several server-level groups. When I start typing group names in the "Specific users" box on the Approvals page of environment properties, one of them ("Application Hosting Team") comes up, another ("QA Team") doesn't. The former is a part of collection admins, the latter has no specific rights. If I grant the QA team collection admin, it comes up, too.
Question - which rights do I have to grant (short of admin) so that TFS considers it eligible for approving releases? Preferably on collection level.
EDIT: Adding the server level group to "Project Readers" will do, but I'd hate to go through all the projects...
Found two collection level ways:
Create a collection level group, add server level group to that one, grant Allow for Edit collection level items
Add the server group to "Release Management Service Accounts"
Either works. The former is slightly more work, the latter might grant more rights than strictly necessary to approve releases.
Related
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've got a TFS server in which team projects exists. These team projects have area paths below them. These area paths represents projects of certain customers. We want to give customers access to their area path.
The problem is when we do that they automatically gain access to all other area paths withing that team project. Is there a way of limiting access so the customers can only see their area path and nothing else?
No such a feature to limit users in team project level with the area path set.
Area path only restricts the users on work items:
Area paths allow you to group work items by team, product, or feature
area. Whereas, iteration paths allow you to group work into sprints,
milestones, or other event-specific or time-related period. Both these
fields allow you to define a hierarchy of paths.
Please see About area and iteration paths (aka sprints) for details.
So, if you don't want to the users see the specific team projects, then you just need to remove the users from the related TFS groups.
If you just want to restrict the users on manage the sources/files or source control on specific Repository/branches, then you can create teams or groups and set the permission accordingly. Please see below articles for details:
Add teams and team members
Permissions and groups in VSTS and TFS
As mentioned in this thread, by design a team can access other teams backlogs and work items.
To deny different teams access to other teams work items I used a workaround which might work for you as well.
The workaround is to use TFS security groups to limit teams access to area paths. By default, every team is created as a member of the default security group [project]\Contributors which gives the team access to all area paths.
Here are the steps I followed:
Create a new security group for every team
Make the new groups members of the Contributors default group
Add every team as a member of its new respective security group
Remove all teams from the Contributors group
In the project's areas admin screen, open each area's context menu and click the security option (check this article)
In the security view, add the newly created security groups
For each group, allow/deny the permissions based on your requirements
Please note, this workaround will not hide other area paths from the users in the not allowed groups. They still can navigate to backlogs of other groups but they will not view or edit the work items. This behavior is same for reports and dashboards as well
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
I use TFS 2013 with one team collection and I have a Project.
This project uses area paths to differentiate between teams.
So I have an area Path/Team lets call it "Inventing".
This Inventing team has a Product Owner who should only do what a product owner is supposed to do in scrum.
I can add this particular person to the area path and allow him the rights.
I want to say: he is the product owner of this AreaPath.
Do I need to create for every area path a TFS Group called "product owner inventing" and add/remove the persons for that TFS Group?
Or is there a better solution?
There is no way you can isolate a specific user role like this from the create wizard by default. So yes, you'll need to create a group for the product owner. Remember that work items have links to change sets, so it might be hard to isolate the product owner completely from viewing any code it's not a simple checkbox to tick.
BTW we often do trust external people with the code they're basically owner of. Non Disclosure Agreements and contracts can get a long way in legally closing that loop. I'd expect that the product owner will look over the shoulder of team members, will have opportunity once in a while to access developer workstations, no matter how hard you secure everything. Trust is important in Scrum and Agile, this is one aspect of trust.
I want to make a TFS 2010 project read-only so users can view the info in work items but not add any details or new work items. I think I need to change the security permission on the project but it's not clear which permission I would change from the Contributors list.
In my opinion the right way is to alter the group memberships.
Remove all users from the constributors and higher groups and move them to the Readers group.
Two choices.
Choice 1: If this is a common pattern where the prevailing default is that folks are restricted, but some people have access (i.e. devs cannot change things but Tech Leads can), modify contributors and create a secondary group (for example, 'Tech Leads') that has the additional read rights. In this scenario, the Contributors group would contain tech leads, but only specific individuals with the extra rights would be in the Tech Leads group.
Choice 2: If the prevailing default is normal contributor access, but specific individuals (i.e. external contractors) need to be denied access, and you need to be 100% sure this goes through, regardless of any other group membership, then leave Contributors as is, and add a new group called (in this example) 'Contractors' and DENY specific access as needed.
Like before, everyone is a contrib, but contractors have some absolute limitations imposed on them, and the 'DENY' in the Contractors group overrides the 'Allow' from contrib. A use case for this would be cases where specific code has to be hidden from external vendors or some other sub-group and needs to be 100% rock solid - just be careful with denies as they will trump any number of allows you inherit from other groups.
Hope that helps!
Addendum: For restricting or changing rights on workitems, you need to do two things. First, set up appropriate group mempership (noted above), then in the project, under Team Project Settings -> Areas and Iterations, click the Security button to set this up on a node by node basis (or at the root if you want to do these restrictions project wide).