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.
Related
In our company, only users with a Project Amin role can update the Iteration Capacity in TFS. Is there a setting we can add to a Contributor role to allow each individual to update their own Capacity for a given Iteration? We do not want to give everyone Admin role as they can change everything on the site, but need every individual to go update their own capacity and add their vacation days ahead of the sprint planning session.
Actually users in your team do not need full Project Admin role to update Iteration Capacity.
You could simply follow below prerequisites:
You must connect to a team project. If you don't have a team project yet, create one in TFS/VSTS.
You must be a member of the Contributors group or be granted Stakeholder access to add or modify work items. Or, you must have
your View work items in this node, and your Edit work items in this
node permissions set to Allow.
If you haven't been added to a team project or team, get added now.
As you can see, you just need to assign the users in contributors group or modify work item in this node permission to allow. More details please take a look at this tutorial-- Set your team's capacity, the same for Iteration.
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
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.
I'm confused by all the stuff in TFS. Can someone please explain how all this fits together?
Team project collection
Team project
Team
Area
Iteration
From this page, I think a (team) project collection can contain multiple (team) projects, which can contain multiple teams. Is that right? Can projects contain other sub-projects? Can teams contain other sub-teams? The team defines a set of people (team members). Anything else?
I think the team can define its own area and iterations, or else inherit them from its parent. Is that right?
Is it possible to parse the area path? For example, when area path is "DSS\ADC\MML" does that always mean that "DSS" is the Project, and "ADC\MML" is the Team?
A Team Project Collection is a database containing a collection of Team Projects.
A Team Project is an organizational unit for source code, work items, build definitions, release definitions, manual tests, etc. You can have multiple Team Projects per Collection. A Team Project can best be thought of as "a collection of software applications and all of the associated artifacts necessary to plan work, build, test, and release the applications".
A Team is an organizational unit within a Team Project allowing multiple teams to work concurrently on different aspects of the software portfolio. Each team can have its own backlog, dashboards, etc. Teams are associated to Areas.
An Area is an organizational unit within a Team Project used for grouping similar work together. An area can be assigned to a Team, meaning any work items that appear in that area are in the domain of that team. Areas can have any hierarchy you want, and the names do not necessarily map to anything like a Team Project name or a Team name.
An Iteration is used for defining your work item backlogs and sprints/iterations. A team is usually assigned a backlog iteration, and then sub-iterations define the sprints and associated start/end dates for work.
Daniel has provided a good answer, but I want to clarify further.
Team, Area, and Iteration are independent partitions of work items.
When you see Area Path = DSS\ADC\MML you should think: Area is ADC\MML within Project DSS.
Likewise, when you see Iteration Path = DSS\ADC\Sprint 23 you should think: Iteration is ADC\Sprint 23 within Project DSS.
Each Work Item belongs to exactly one area and exactly one iteration. You can imagine all the work items within a two dimensional grid of Area and Iteration, as below.
Just like Area and Iteration, a Team exists within a single Project. When you see Team = DSS/MML Dev you should think: Team is MML Dev within Project DSS. Notice that, unlike Area and Iteration, the Team uses forward slashes and the Team cannot be hierarchical.
The Work Items are not associated with a Team. Instead each Team can be associated with any subset of Areas and/or Iterations with the project. (To change the Areas and Iterations assigned to a Team, click the Manage Team gear icon in the top right corner of the web page). Therefore the Team is indirectly associated with a set of Work Items. The relation between Team and Work Item is many-to-many.
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).