LDSTechForumProjects

Setting TFS Permissions

This article is in a draft stage.


This article specifies step-by-step instructions on how to set appropriate permissions in TFS for accessing various items. The list of items that need permissions set include Work Items, Builds, Source Control, Tests, Areas and Iterations, Drop Folders, Reports, and Team SharePoint Portal and Dashboards. As a general rule, you should assign permissions to groups as much as possible and avoid granting specific permissions to an individual. However, in the details in each section below it will be shown how to do both.

To grant permissions to the various items, you will have to possess certain permissions. If you do not have sufficient permissions to grant access to certain items, you will need to contact the .NET Stack Team and request such rights.

References to helpful webpages or blog posts are given for more information on the topic being presented. These links cannot be guaranteed, but if valid will provide more details and are worth clicking on to gain more insight.

Setting Work Item Permissions

There are many different kinds of Work Items in TFS. Out-of-the-box each new Team Project defines the following Work Items: Bug, Issue, Shared Steps, Task, Test Case, and User Story. However, TFS provides the ability to create new Work Item types using the witadmin.exe utility and then customize them in Visual Studio using the Process Editor tool.

To see the current Work Item permissions for your Team Project there are two places to go:

  1. In Team Explorer, right click on your project name and select Team Project Settings.
  2. You will need to view the settings under both the Security... and Group Membership... options to identify the full Security Permission settings for your project.
    • The Security... option shows which Work Item permissions are assigned to each User or Group.
    ProjectSecuritySettings.png
    • The Group Membership... option shows the members of each group if you highlight the Group and click on the Properties button.
    GroupMembershipSettings.png

The Project Security Permissions that may be set for each User or Group are:

  • Create test runs
  • Delete team project
  • Delete test runs
  • Edit project-level information
  • Manage test configurations
  • Manage test environments
  • View project-level information
  • View test runs


At the Project Collection level, the Security Permissions that may be set for each User or Group are:

  • Administer Project Server integration
  • Administer shelved changes
  • Administer workspaces
  • Alter trace settings
  • Create a workspace
  • Create new projects
  • Delete team project
  • Edit collection-level information
  • Make requests on behalf of others
  • Manage build resources
  • Manage process template
  • Manage test controllers
  • Manage work item link types
  • Trigger events
  • Use build resources
  • View build resources
  • View collection-level information
  • View system synchronization information


Each setting can be selected or deselected to Allow or Deny the User or Group that specific permission. If a user needs the same permissions to which a Group has already been assigned, then you should add the user to that Group. If there is a Project Collection Permission setting that you want to change, but don't have rights then contact the .NET Stack Team.

To block creation of a particular Work Item, unless the user is a member of a particular Group, see the blog post on Work Item Rules Workarounds: Secure creation of a work item type.

To allow certain users to only see and edit their own Work Items, you can add them to the Security Group "Work Item Only View." Read the Work Item Only View (WIOV) Users in TFS 2010 blog post for more details.

Setting Build Permissions

In TFS 2010, the permission settings for builds are more granular than they have ever been. To set permissions on builds for the Team Project, follow these steps:

  1. Connect to your Team Project in Team Explorer in Visual Studio.
  2. Right click on the Builds folder.
  3. Select Security...
  4. In the Security dialog, you can select a Group or User in the list to view or modify their permissions or you can add a new User or Group and assign permissions.

If there is a Group that has the desired permissions for managing builds, then you can simply add a user to that Group and no other changes are necessary.

ProjectSecurityPermissionsDialog.png
Project Security Permissions dialog

To set permissions at the Build Definition level, in step 2 above, right click on a Build definition in the Builds folder rather than on the Builds folder itself.

Here are the permission settings that you can either Allow or Deny for Users or Groups:

  • View builds
  • Edit build quality
  • Retain indefinitely
  • Delete builds
  • Manage build qualities
  • Destroy builds
  • Update build information
  • Queue builds
  • Manage build queue
  • Stop builds
  • View build definition
  • Edit build definition
  • Delete build definition
  • Override check-in validation by build

Also, there is a TFSSecurity.exe command-line utility that can be used for setting Build permissions. For more detailed information about this tool, see the Changing Groups and Permissions with TFSSecurity article on MSDN.

Setting Source Control Permissions

The easiest way to grant user access to the Source Code of a particular Team Project is to add them to the Contributors Group. That will automatically give them rights to check-in and check-out Source Code.

However, you can manage permissions much more granular than that if you wish. You can grant access control permissions to Windows Groups, Windows Users, and Team Foundation Groups. Permissions will be inherited from the containing folder or you can explicitly declare permissions. To declare permissions explicitly, follow these steps:

  1. In Visual Studio, click View > Other Windows > Source Control Explorer.
  2. Right click the folder or file for which you want to set permissions and then click Properties.
  3. In the folder's (or file's) Properties dialog box, click the Security tab.
  4. In the Add users and groups area, select Team Foundation Server Group to set permissions for a Team Foundation Server Group, or to grant rights to a user or LDS Group select Windows user or group.
  5. Click on the Add button.
  6. Identify the user or group to be added in the Select Users, Computers, or Groups dialog.
  7. Close the Select Users, Computers, or Groups dialog when the users or groups have been identified by clicking on the OK button.
  8. Set the Allow and Deny privileges as you see fit.

Note: Deny always overrides Allow.

See the image below to view the dialogs mentioned above.

GrantingSourceCodeUserPermissions.png
Granting a user permissions to Source Code

One area of concern regarding Source Control Permissions is how to set permissions on a branch. There is a good TFS Branching Guidance article that describes how to handle permissions for branches. Here is an excerpt:

In terms of source control, permissions in TFS 2010 can be granted separately from permissions to team projects, work items, portals and reporting services. A user may have distinct permissions on each branch to which they have access. Permissions may be inherited or granted explicitly. For each branch that you wish to set permissions to, take the following steps as referenced in the MSDN article "How to: Control Access to Team Foundation Version Control."
Branch permissions will have the same permissions as the main branch it was created from. It is important to set the permissions to a more restrictive level immediately after the branch is created.
It is good practice to set permissions to the level of access actually needed rather than using a more generalized model. Ideally, branch permissions should be restricted to your team members that actually require access to source code. The permissions should be specific to the branch rather than inherited. Implementing this practice will make your branches more secure against changes that were not meant for your branch. Otherwise, it can easily happen that a developer checks in code to the wrong branch by accident. One scenario would be to grant all external developers access to a development branch but not to your main branch. The specified permissions on your main branch control who is allowed to merge the changesets from the development branch to the main branch.

Setting Test-Related Permissions

There are several parts to granting rights to someone in QA that needs to do testing using the TFS 2010 tools. They need rights to the following:

  1. TFS Team Project
  2. Source Control Depot
  3. Test Controller
  4. SharePoint Portal Dashboard and Reports
  5. Analysis Services
  6. Reporting Services

Refer to the next few sections for more details about granting permissions to each of these six areas.

TFS Team Project Permissions

A QA person will need access to the TFS Team Project that they work on as part of their job. This is usually completed by their Team Project Administrator adding them to the Team Project. When a new project is created, the .NET Stack Team will grant Administrator rights to at least one person on the team. That person can follow these steps to grant permissions to the rest of his team:

  1. In Visual Studio, right click on the Team Project in Team Explorer.
  2. Expand the Team Project Settings option to display the submenu.
  3. In the submenu, click on the Group Membership... option to open the Project Groups on <ProjectName> dialog.
  4. Click on the Group where team members will reside, for example Contributors, and click the Properties... button to open the Team Foundation Server Group Properties dialog.
  5. Select the Windows User or Group radio button.
  6. Click the Add... button to open the Select Users, Computers, or Groups dialog.
  7. Type in the name of the Team Member, or the name of an LDS Group, to add to the TFS group.
  8. Click the Check Names button to resolve the name to their LDS Account.
  9. Click OK to close the Select Users, Computers, or Groups dialog.
  10. Click OK again to close the Team Foundation Server Group Properties dialog.
  11. Click Close to close the Project Groups on <ProjectName> dialog.
AddingTeamMemberToTFSGroup.png
Adding a Team Member to a TFS Group

Source Control Depot Permissions

A team member who will be doing automated testing will need rights to the Source Code Depot (repository) to check in their test code. This can be done by a TFS Team Project Administrator or the .NET Stack Team member. a TFS Team Project team member should receive rights by being added to a group in TFS (for example, the Contributors group). The previous section describes how to add a team member to a TFS Group.

To grant rights to a user that is not in a TFS Group so they can access the TFS Team Project source code, refer to the section on Setting Source Control Permissions.

Test Controller Permissions

In Microsoft Test Manager (MTM), it is possible to run all automated tests on a remote machine. A tester will need rights to a Test Controller so that the automated tests can be sent to the Controller. Test Agent machines are registered with a Test Controller and will run any tests sent to that Controller. The Tester does not need rights to all the individual Test Agents, but does need rights to the Test Controller. That way in MTM they will be able to see the Controller and add it to their Test Environments.

The Test Controller and Test Agent software can be installed on a machine and the Agents can be configured without granting any rights. However, the Test Controller must be registered with TFS and added to the TFS Collection. For that a user would have to be a member of the TFS Project Collection Administrators Group. At this point, either the user would need to be added to the TFS Project Collection Administrators Group (see a previous section to read on how to add a user to TFS Group) or a member of the .NET Stack Team who already has rights to the collection could follow the steps below to add the Test Controller to the collection.

  1. Run the Configure Test Controller utility that is available on the machine where the Test Controller software is installed.
  2. Select the check box that says Register with Team Project Collection.
  3. In the field entitled Register the test controller with the following Team Project Collection:, type in the URL to the TFS Collection.
  4. Click Apply Settings and ensure that the status dialog shows that the Test Controller was successfully added to the Collection.
  5. Click OK to close the Configure Test Controller utility.
TestControllerConfigurationUtility.png
Test Controller Configuration Utility

SharePoint Portal Dashboard and Reports Permissions

A team member responsible for QA will not need any additional privileges for the SharePoint Portal than anyone else on the team. See the section on Setting SharePoint Portal Permissions.

Analysis Services Permissions

To grant rights on the Analysis Services server, it will be necessary to start Microsoft SQL Server Management Studio. The Analysis Services server is a SQL Server and has the server type of Analysis Services. Use the following steps:

  1. In Microsoft SQL Server Management Studio, connect to the Analysis Services server whose name is chqpvuw1517\AS02.
    MicrosoftSQLServer.png
  2. Click Connect.
  3. In the left pane, expand the Databases folder.
  4. Then expand the Tfs_Analysis and Roles folders.
  5. Double click the Role TfsWarehouseDataReader which will open the Edit Role dialog.
  6. On the left side of the dialog, click Membership.
  7. Click the Add... button which will open the Select Users or Groups dialog.
  8. Type in the name of the user of group to add to the Role and click Check Names.
  9. Click OK to close the Select Users or Groups dialog.
  10. Click OK again to close the Edit Role dialog.
  11. Close the Microsoft SQL Server Management Studio application.
EditRoleDialog.png
Edit Role dialog

Reporting Services Permissions

A Tester will need rights to the Reporting Services if they are responsible for generating new charts or graphs and posting them on the SharePoint Portal. However, if the team is alright with using the existing out-of-the-box charts on the Dashboard for Test Results, Bugs, and so on, then the Tester will not need rights to the Reporting Services.

To grant rights to a user so they can create customized graphs, charts, or reports, see the section of this article on Setting Reports Permissions.

Setting Area and Iteration Permissions

When a project is initially created, the areas of functionality will need to be laid out in a hierarchical structure under which work items can be classified. Initially and for each new Sprint or Milestone for a project, it will be necessary to add one or more iterations. You must have rights to the Areas and Iterations under the Project Security to be able to Create, Delete, Edit or View the nodes in the hierarchy.

To grant users rights to manage the hierarchy of Areas or Iterations, follow these steps:

  1. In Visual Studio, right click the name of the project in Team Explorer.
  2. Select Team Project Settings and then Areas and Iterations... which will open the Areas and Iterations dialog.
  3. There are two tabs, Area and Iteration, and the default is Area. Click the tab for which you want to manage.
  4. There are icons for each of the actions that you would like to perform, such as Add a child node, delete a node, or reorder or move a node, either up or down in the hierarchy.
    AreasAndIterationsDialog.png
  5. Click the Security... button to open the Project Security dialog.
  6. Select the user or group to modify and then select or deselect the Permissions check boxes to Allow or Deny each one.
  7. If the user or group is not listed, then do the following:
    • Click the Windows User or Group radio button.
    • Click the Add... button which will open the Select Users, Computers, or Groups dialog.
    • Type in the user or group name and click Check Names.
    • Click OK to close the Select Users, Computers, or Groups dialog.
  8. Click Close to close the Project Security dialog.
  9. Click Close to close the Areas and Iterations dialog.
ProjectSecurityDialog.png
Project Security dialog

Setting Drop Folder Permissions

For users that need to get builds and deploy them to a Test, Dev, Stage, or Production environment (for example, an ASE) they will need rights to the Drop location. All builds are dropped after a successful compilation to the following share: \\icstfsdrop\drop\<ProjectName>. Some teams have a script that will copy the successful build to a Pub share on \\icstfsdrop. This practice, however, is discouraged since it takes up more disk space for no additional benefit.

You might find that following these instructions to grant permissions to individual users will be slow to complete, depending on the number of files and folders below your drop folder that need to have their Access Control Lists modified.

We recommend using Active Directory groups (such as Admins, Contributors, Readers) to manage the rights of your drop folder. Adding users to those groups is both faster to complete and easier to manage than trying to add individuals to your drop folder.

To grant rights for a group to get a build or to drop a build, follow these steps:

  1. Remotely connect to the icstfsdrop machine. If you do not have rights to be able to remotely sign in to that machine, then you should be able to map a drive to the project folder on the drop share for which you are an admin.
  2. In the File Explorer, navigate to the folder where you want to grant the group access.
  3. Right click the folder and select Properties.
  4. In the folder's Properties dialog, go to the Security tab.
  5. If the user is not listed, then do the following:
    • Click on the Add... button to open the Select Users, Computers, or Groups dialog.
    • Type in the user or group name and click Check Names.
    • Click OK to close the Select Users, Computers, or Groups dialog.
  6. Select the user or group in the list and the current Permissions will be displayed.
  7. Select or deselect the check boxes in the Allow or Deny column to specify the desired access levels.
  8. Click OK to close the folder's Properties dialog. It may take a while for this to complete since it will apply the permission changes to all files in the folder and all sub-folders.

Setting Reports Permissions

Reporting Services permissions cannot be set using Visual Studio. To set permissions for accessing Reporting Services, use the TFS Administration Tool which is available on the CodePlex site. Using this utility, you can grant the various available Reporting Services permissions to any user that has an LDS Account and assign the user to Reporting Services Roles.

The following are steps to grant Reporting Services rights to a user:

  1. Download and install the TFS Administration Tool 2.1.
  2. Run the TFS Administration Tool 2.1 utility.
  3. Click Connect at the top of the UI to open the Connect to Team Project dialog.
  4. Select from the drop down list the TFS Server which is icstfs.ldschurch.org. If there are no servers showing in the drop down menu, follow these steps:
    • Click Servers... to open the Add/Remove Team Foundation Server dialog.
    • Click the Add... button to open the Add Team Foundation Server dialog.
    • Type in the name of the TFS Server, icstfs.ldschurch.org, in the Name field. Leave the Path, Port number, and Protocol fields with their default values.
    • Click OK to close the Add Team Foundation Server dialog.
    • Click Close to close the Add/Remove Team Foundation Server dialog.
  5. Select the check box(es) that correspond(s) to the project(s) you want to administer.
  6. Click Connect.
  7. In the left pane, double click a project name.
  8. In the right pane, double click a user to open the User(s) Information dialog. If the user to which you want to grant privileges is not listed, then follow these steps:
    • Click the Add User(s) icon at the top of the page which will open the User(s) Information dialog.
    • Click Browse to open the Select Users, Computers, or Groups dialog.
    • Type in the user or group name and click Check Names.
    • Click OK to close the Select Users, Computers, or Groups dialog.
  9. In the three lists at the bottom of the User(s) Configuration dialog, select the check boxes that correspond to the roles you wish the user to obtain. The far right list is the list of Reporting Services Roles. These roles include Browser, Content Manager, My Reports, Publisher, Report Builder, and Team Foundation Content Manager.
    • It will not hurt anything to grant all of these Roles to a user. They will be able to view, create, update, delete, and post any report.
  10. Click OK to close the User(s) Configuration dialog.
  11. Click the Commit Changes button in the lower pane to apply the permission changes.
  12. Close the TFS Administration 2.1 tool.
TFSAdministrationTool.png
TFS Administration Tool

Setting SharePoint Portal Permissions

SharePoint Portal permissions cannot be set using Visual Studio. There are two means of granting SharePoint rights and privileges. One way to set permissions for accessing a Team SharePoint Portal is to use the TFS Administration Tool which is available on the CodePlex site. Using this utility, you can grant the various available SharePoint permissions to any user that has an LDS Account and assign the user to TFS Roles.

The following are steps to grant SharePoint Portal rights to a user:

  1. Download and install the TFS Administration Tool 2.1.
  2. Run the TFS Administration Tool 2.1 utility.
  3. Click Connect at the top of the UI to open the Connect to Team Project dialog.
  4. Select from the drop down list the TFS Server which is icstfs.ldschurch.org. If there are no servers showing in the drop down menu, follow these steps:
    • Click Servers... to open the Add/Remove Team Foundation Server dialog.
    • Click the Add... button to open the Add Team Foundation Server dialog.
    • Type in the name of the TFS Server, icstfs.ldschurch.org, in the Name field. Leave the Path, Port number, and Protocol fields with their default values.
    • Click OK to close the Add Team Foundation Server dialog.
    • Click Close to close the Add/Remove Team Foundation Server dialog.
  5. Select the check box(es) that correspond(s) to the project(s) you want to administer.
  6. Click Connect.
  7. In the left pane, double click a project name.
  8. In the right pane, double click a user to open the User(s) Information dialog. If the user to which you want to grant privileges is not listed, then follow these steps:
    • Click the Add User(s) icon at the top of the page which will open the User(s) Information dialog.
    • Click Browse to open the Select Users, Computers, or Groups dialog.
    • Type in the user or group name and click Check Names.
    • Click OK to close the Select Users, Computers, or Groups dialog.
  9. In the three lists at the bottom of the User(s) Configuration dialog, select the check boxes that correspond to the roles you wish the user to obtain. The middle list is the list of SharePoint roles. These roles include Contribute, Design, Full Control, Read, and View Only.
    • Usually only the Contribute role is assigned to team members. A Team Admin would want Full Control.
  10. Click OK to close the User(s) Configuration dialog.
  11. Click the Commit Changes button in the lower pane to apply the permission changes.
  12. Close the TFS Administration 2.1 tool.
TFSAdministrationTool.png
TFS Administration Tool

The other way of granting SharePoint permissions is to go to the SharePoint Portal of the TFS Team Project. The URL will be https://teams.ldschurch.org/tfs/<ProjectName>. Here are the steps:

  1. On the SharePoint Portal page, click on the Site Actions drop down in the upper left corner.
  2. Select the Site Permissions option.
  3. Click Grant Permissions to open the Grant Permissions dialog.
  4. Type in the user or group name and click the Check Names icon which is of a person next to a blue check mark.
  5. If the user or group name resolves, then you can either add them to a SharePoint group or explicitly set the permissions for that user.
    • It is typically a better practice to add them to a group and let the permissions be set on a group or users.
    • If the Grant users permission directly option is selected, then they can be given one of the following rights: Full Control, Design, Contribute, Read, or View Only.
  6. It may be beneficial to select the Send welcome e-mail to the new users check box so the user is notified that they now have permissions to the SharePoint Portal. The e-mail will also provide a link to the site.
  7. Click OK to close the Grant Permissions dialog.
GrantingSharePointPermissions.png
Granting SharePoint Permissions

Granting Cube Permissions

For people to be able to create custom SharePoint charts and graphs, either through Excel or SSRS, they will need to have access to the TFS Data Warehouse, otherwise known as the TFS Cube. The following are the steps for granting the necessary permissions:

Note: Only certain people on the ALM Stack Team have permissions to grant these rights, so it is likely that you will have to send an e-mail to tfs@ldschurch.org and ask someone to grant you rights to the TFS Cube.

  1. Start SQL Server Management Studio.
  2. In the initial dialog box, type in the name of the Analysis Services Server, which in ICS is chqpvuw1517/AS02, and click Connect.
    MicrosoftSQLServer.png
  3. If you have rights to administer the TFS Analysis Services, then you will see the main Server Management Studio screen.
    SQLServerManagementStudio.png
  4. Expand Databases, then Tfs_Analysis and then Roles.
  5. Double click TfsWarehouseDataReader.
    TFSWarehouseDataReader.png
  6. In the left pane of the Edit Role - TfsWarehouseDataReader dialog, click on Membership.
  7. To add a new user to this list, click Add...
    TFSWarehouseDataReaderDialog.png
  8. Type in the user name in the Enter the object names to select (examples): field.
  9. Click on Check Names to resolve the name to an LDS Account.
  10. Click OK to dismiss the Select Users or Groups dialog.
    SelectUsersOrGroupsDialog.png
  11. Click OK to close the Edit Role - TfsWarehouseDataReader dialog.
  12. Close the Microsoft SQL Server Management Studio application.
This page was last modified on 20 November 2013, at 11:52.

Note: Content found in this wiki may not always reflect official Church information. See Terms of Use.