Compartir a través de


Permission reference for Team Foundation Server

Permissions determine what tasks users can and can’t do. For users to have access to Team Foundation Server (TFS) resources and team projects, you need to add them to a team project or TFS group. For an overview of how TFS manages membership, permissions, and access, see Manage users and groups in TFS.

This topic describes TFS permissions and their default assignments to each of the built-in TFS groups. It also explains the tools you can use to set permissions. There are three categories of built-in groups, four permissions levels, and five permission states. Each user’s access to a functional task depends on the explicit or inherited permission state assigned to them or to a group to which they belong.

In this topic

  • What’s new in permissions?

  • Tools used to set permissions

  • Built-in TFS groups

    • Server-level groups

    • Collection-level groups

    • Project-level groups

  • Allow, Deny, Not set, and other permission states

    • Inheritance

    • Do’s and Don’ts when setting permissions

  • Server-level permissions

  • Collection-level permissions

  • Project, test, and object-level permissions

    • Project and test-level permissions

    • Build-level permissions

    • Work item query

    • Tagging

    • Area-level for work item tracking

    • Iteration-level for work item tracking

    • Team Foundation Version Control

    • Git repository

  • Lab Management

  • Release Management

Default TFS groups and permission levels

To assign permissions for SharePoint Products or SQL Server Reporting Services, see Add users to team projects and Grant permissions to view or create reports in TFS.

What's new in permissions?

Additions and changes to the TFS permission model are noted in the following table. They are based on the version you have installed on your application-tier server.

TFS version

New or changed permissions

TFS 2013.3

Manage test suites permission added, and Manage test plans permission re-scoped to manage only test plans. These permissions are set for an area path. Previously, it covered permission management of both test plans and test suites.

TFS 2013.2

Tagging permissions added.

TFS 2013

Git repository permissions added.

Tools used to set permissions

You can use the tools listed in the following table to set permissions. Different tools are used depending on whether you are setting permissions at a server, collection, or project-level. You use Team Web Access (TWA) to set most permissions for users and groups to access a team project.

Permission level

TWA administrative page or object-level security

Team Explorer (Note 1)

Team Foundation Administration Console

TFSSecurity command-line tool

Tf command- line tool

TFSLabConfig command line tool

Server-level

check mark

check mark

Collection-level

check mark

check mark

check mark

check mark

Project and test-level

check mark

check mark

check mark

Build-level

check mark

check mark

Work item query

check mark

check mark

check mark

Tagging

check mark

Area-level for work item tracking

check mark

check mark

check mark

Iteration-level for work item tracking

check mark

check mark

check mark

Team Foundation Version Control

check mark

check mark

Git repository

check mark

check mark

Lab Management

check mark

Release Management (2)

Notes

  1. Some permission options that you access from Team Explorer open a user interface in Team Web Access.

  2. If you add Release Management to your deployment, you can manage permissions using groups that you define in Release Management, TFS, or Active Directory. You manage permissions through the Release Management client.

Another tool that you can use to manage user membership within groups is the TFSAdmin tool from CodePlex.

Command-line tools, namespaces, and permission names

When you exercise the TFSSecurity command-line tool to manage permissions, you specify a namespace as well as the name of the permission. In the sections below, the namespace and command name are indicated. There are two namespace groups: project collection and server. Use the TFSSecurity /a command to list the namespaces. To obtain the set of permissions you can set under a namespace, use TFSSecurity /a Namespace /collection:CollectionNameURL

Project collection namespaces

Server namespaces

TFSSecurity /a /collection:CollectionNameURL

Build
BuildAdministration
Chat
Collection
CSS
Discussion Threads
EventSubscription
Git Repositories
Identity
Iteration
Job
Project
ProjectServerAdministration
Registry
Server
ServiceHooks
StrongBox
Tagging
TeamLabSecurity
VersionControlItems
VersionControlPrivileges
WorkItemQueryFolders
WorkItemTrackingAdministration
WorkItemTrackingProvision
Workspaces

TFSSecurity /a /server:ServerNameURL

Catalog
CollectionManagement
Diagnostic
EventSubscription
Feature Availability
HostingAccount
Identity
Job
Lab
Registry
Server
StrongBox
Warehouse
WebAccess

Built-in TFS groups

When you install TFS, four groups are defined at the server level. When you create a project collection, seven groups are created at the collection-level, and for each team project that you create, six groups are created that are scoped to the team project. Each of these groups is associated with a set of default permissions. You can’t remove or delete a default server-level groups, such as the Team Foundation Administrators group.

Server-level

Collection-level

Project-level

  • SharePoint Web Application Services

  • Team Foundation Administrators

  • Team Foundation Service Accounts

  • Team Foundation Valid Users

  • Project Collection Administrators

  • Project Collection Build Administrators

  • Project Collection Build Service Accounts

  • Project Collection Service Accounts

  • Project Collection Proxy Service Accounts

  • Project Collection Test Service Accounts

  • Project Collection Valid Users (Note 1)

  • Build Administrators

  • Contributors

  • Project Administrators

  • Project Valid Users (Note 1)

  • Readers

  • TeamProject group (Note 2)

Notes:

  1. To learn more about valid user groups, jump to this What is a Valid User? How are Valid User groups populated? section.

  2. A team group is created with the name of the team project. For example, if you create a team project named "Code Sample," a team group will also be created with the name "Code Sample Team." You can rename this team.

    In addition, when you create additional teams, a team group is created for each team.

Server-level groups are assigned server-level permissions. Collection-level groups are assigned permissions defined for the collection, project, and objects. And, permissions assigned to project-level groups include both project-level and object-level.

For example, the following picture shows the permissions assigned to the project-level Contributor group.

Contributor role default permissions

The Project administrator group permissions include those assigned to the Contributor group and a few more.

Project Admininistrator role default permissions

Server-level groups

By default, the following groups exist at the server level for the application-tier when you install TFS.

Group name (prefix: Team Foundation\

Permissions

Default user accounts

Team Foundation Administrators   

Can perform all operations for TFS. This group should be restricted to the smallest possible number of users who need total administrative control over TFS.

Local Administrators group (BUILTIN\Administrators) for any server that hosts Team Foundation application services.

Server\Team Foundation Service Accounts group and the members of the \Project Server Integration Service Accounts group.

Team Foundation Valid Users   

Have read access to source code, work items, and build definitions. Access to TWA features is dependent on the license or access level group they’ve been assigned.

Important

If you set the View instance-level information permission to Deny or Not set for this group, no users will be able to access the deployment.

Contains all users and groups that have been added anywhere within TFS.

You can’t modify the membership of this group.

Team Foundation Service Accounts   

Have service-level permissions for TFS.

Contains the service account that was supplied during installation.

This group should contain only service accounts and not user accounts or groups that contain user accounts. By default, this group is a member of Team Foundation Administrators.

Project Server Integration Service Accounts   

Have service-level permissions for the Project Server deployments that are configured for interoperation with TFS. In addition, members of this group have some TFS service-level permissions.

This group should contain only service accounts and not user accounts or groups that contain user accounts. By default, this group is a member of Team Foundation Administrators.

SharePoint Web Application Services   

Have service-level permissions for the SharePoint Web applications that are configured for use with TFS, in addition to some service-level permissions for TFS.

This group should contain only service accounts and not user accounts or groups that contain user accounts. Unlike the Service Accounts group, this group is not a member of Team Foundation Administrators.

Team Foundation Proxy Service Accounts

Members of this group have service-level permissions for Team Foundation Server Proxy, and have some TFS service-level permissions.

This group should contain only service accounts and not user accounts or groups that contain user accounts.

Collection-level groups

By default, the following groups exist at the collection level when you configure a collection.

Group name (prefix: TeamProjectCollectionName\

Group-level permissions

Account assignments

Project Collection Administrators   

Can perform all operations for the team project collection.

Contains the Local Administrators group (BUILTIN\Administrators) for the server where the application-tier services for TFS have been installed. Also, contains the members of the TeamProjectCollectionName\Service Accounts group.

This group should be restricted to the smallest possible number of users who need total administrative control over the collection.

Project Collection Valid Users

Can access team projects defined for the collection.

Important

If you set the View collection-level information permission to Deny or Not set for this group, no users will be able to access the collection.

Contains all users and groups that have been added anywhere within the team project collection. You cannot modify the membership of this group.

Project Collection Service Accounts  

Have service-level permissions for the collection and for TFS.

Contains the service account that was supplied during installation. This group should contain only service accounts and groups that contain only service accounts. By default, this group is a member of Team Foundation Administrators and Team Foundation Service Accounts.

Project Collection Build Administrators   

Can administer build resources and permissions for the collection.

Limit this group to the smallest possible number of users who need total administrative control over build servers and services for this collection.

Project Collection Build Service Accounts

Have those permissions required to run build services for the collection.

Limit this group to service accounts and groups that contain only service accounts.

Project Collection Proxy Service Accounts   

Have permissions required to run the proxy service for the collection.

Limit this group to service accounts and groups that contain only service accounts.

Project Collection Test Service Accounts   

Have test service permissions for the collection.

Limit this group to service accounts and groups that contain only service accounts.

Project-level groups

By default, the following groups exist when you create a team project. Their permissions are scoped to the project level.

Group (prefix: ProjectName\)

Group-level permissions

Additional notes

Project Administrators   

Can administer all aspects of the team project, although they can’t create projects.

Assign to users who will manage user permissions, create teams, define area an iteration paths, or customize work item tracking.

Build Administrators   

Can administer build resources and build permissions for the project. Members can manage test environments, create test runs, and manage builds.

Contributors   

Can contribute fully to the project code base and work item tacking.

By default, the team group created when you create a team project is added to this group, and any user you add to the team will be a member of this group. In addition, any team you create for a team project will be added to this group by default, unless you choose a different group from the list.

Readers

Can view the project but not modify it.

Assign to stakeholders who want to be able to view work in progress.

TeamName   

Inherit the same permissions assigned to the Contributors group. Can contribute fully to the project code base and work item tacking.

The default Team group is created when you create a team project, and by default is added to the Contributors group for the team project. Any new teams you create will also have a group created for them and added to the Contributors group.

Besides these project-level groups, two collection-level groups also appear in every project in TFS:

  • TeamProjectCollectionName**\Project Collection Administrators**

    You cannot change the permissions for this collection-level group.

  • TeamProjectCollectionName**\Project Collection Build Service Accounts**

    Do not remove or set the View project-level information permission to Deny for this group.

Allow, Deny, Not set, and other permission states

TFS uses a least-permissive model for security permissions. What that means is that if a user belongs to two groups and the same permission is assigned Allow for one group and Deny for another group, Deny takes precedence over Allow. There are a few exceptions to this rule for those who belong to the Project Collection Administrator and Team Foundation Server Administrator groups.

You can specify two explicit authorization states for permissions: Deny and Allow. In addition, there are three other states: Inherited allow, Inherited deny, and Not set. Not set is an implicit Deny state.

Permission

Authorization

Allow

Explicitly grants users to perform the task associated with the specific permission. Allow is usually inherited from group membership. For users to access a task, the associated permission must be set to Allow or Inherited allow.

Deny

Explicitly prevents users from performing the task associated with the specific permission. Deny is usually inherited from group membership.

Inherited allow/Inherited deny

Allows or denies a user to perform the task associated with the permission based on the permission set for a group to which the user belongs.

Not set

Implicitly prevents users from performing the action associated with the permission.

Because the permission is neither explicitly set to Deny nor explicitly set to Allow, authorization for that permission can be inherited from other groups of which the user or group is a member.

By default, most permissions are not set to either Deny or Allow. The permissions are left Not set.

Permission states follow these precedence settings:

  • The Deny permission takes precedence over all other permission settings, including Allow. For example, a user might belong to two groups in a project. For one group, Publish test results permission is set to Deny; the other group has that permission set to Allow. The Deny setting takes precedence and the user is not authorized to publish test results.

    Exceptions to this rule are:

    • The Deny permission does not take precedence if it is inherited from a hierarchical parent. These functions support hierarchical permission setting:

      • Source control folders for Team Foundation version control

      • Git repositories

      • Area and iteration nodes for work item tracking

      • Work item shared queries and query folders

      The explicit permissions that are set on a particular object─such as a source control folder, a repository, or an area child node─override those that are inherited from the parent objects. For example, the Deny set for a source control folder doesn’t override an Allow set for one of its sub-folders.

    • When a user belongs to an administrators group, such as the Project Collection Administrators or Team Foundation Administrators groups, unless otherwise stated in the description of the permission.

  • Inherited allow takes precedence over Not set.

Inheritance

When permission is Not set for a user or group, the user or group can be affected by the explicit state for the permission for groups to which they belong because permissions in TFS are inherited. For example, when you review the permissions for a user or group, you might see both Allow and Inherited allow set for permissions. The latter permission is inherited from some other group the user or group belongs to. In this example, a user might belong to a group at the project level and a group at the collection level in a project. If one of those groups has a permission that is explicitly set to Allow and the other group has the same permission Not set, the user will have the Inherited allow permission to perform the actions that are controlled by that permission. The user inherits permissions from both groups, and the Allow permission takes precedence over the Not set permission.

Permission inheritance

To understand why a permission is inherited, you can pause over the permission setting, and then choose Why?. A new window will open. It displays the inheritance information for that permission.

Security page, Contributor role, permissions

Some object-level Security dialog boxes provide an Inheritance on/off option. Use this option to disable inheritance for folders, shared queries, and other objects.

Security dialog box with Inheritance option

Do’s and Don’ts when assigning permissions

Do’s:

  • Use Windows groups when managing lots of users.

  • Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project.

  • When adding many teams, consider creating a Team Administrators group to TFS where you allocate a subset of the permissions available to Project Administrators.

  • When adding teams, consider what permissions you want to assign to team leads, scrum masters, and other team members who may need to create and modify area paths, iteration paths, and queries.

Dont’s:

  • Don’t add accounts to the Readers group that you’ve added to the Project Administrators group. Doing so causes a Deny state to be assigned to several permissions.

  • Don’t change the default assignments made to a valid users group. If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group will be able to access the team project, collection, or deployment, depending on the group you set.

  • Don’t assign permissions that are noted as ‘Assign only to service accounts’ to user accounts.

Server-level permissions

Server-level permissions grant permissions that can affect every project and collection in the deployment. You can set server-level permissions from the Team Foundation Administration Console or using the TFSSecurity command line tool.

You can set these permissions for server-level users and groups, such as Team Foundation Administrators, and for server-level custom groups that you add.

Permission name

TFSSecurity Action

TFSSecurity Namespace

Description

SharePoint Web Application Services

Team Foundation Administrators

Team Foundation Service Accounts

Administer warehouse (Note 1)

Administer

Warehouse

Can process or change settings for the data warehouse or SQL Server Analysis cube by using the Warehouse Control Web Service.

check mark check mark

Create team project collection

CreateCollection

CollectionManagement

Can create and administer team project collections.

check mark check mark

Delete team project collection (Note 2)

DeleteCollection

CollectionManagement

Can delete a team project collection from the deployment.

check mark check mark

Edit instance-level information (Note 3)

GENERIC_WRITE

tf: AdminConfiguration

tf: AdminConnections

Server

Can edit server-level permissions for TFS users and groups, and add or remove server-level groups from the collection.

check mark check mark

Make requests on behalf of others

Impersonate

Server

Can perform operations on behalf of other users or services. Only assign to service accounts.

check mark check mark

Trigger events

TRIGGER_EVENT

Server

Can trigger TFS alert events. Only assign to service accounts and members of the Team Foundation Administrators group.

check mark check mark

Use full Web Access features (Note 4)

FullAccess

Server

Can use all TWA features.

check mark check mark

View instance-level information (Note 5)

GENERIC_READ

Server

Can view server-level group membership and the permissions of those users.

check mark check mark check mark

Notes:

  1. Additional permissions may be required to fully process or rebuild the data warehouse and Analysis cube.

  2. Deleting a team project collection will not delete the collection database from SQL Server.

  3. Edit instance-level information includes the ability to perform these tasks for all team projects defined in all project collections defined for the instance:

    • Add and administer teams and all team-related features

    • Create and modify areas and iterations

    • Edit check-in policies

    • Edit shared work item queries

    • Edit project-level and collection-level permission ACLs

    • Create and modify global lists

    • Edit event subscriptions (email or SOAP).

    When set through the menus, the Edit instance-level information permission also implicitly allows the user to modify version control permissions. To grant all these permissions at a command prompt, you must use the tf.exe Permission command to grant the AdminConfiguration and AdminConnections permissions in addition to GENERIC_WRITE.

  4. If the Use full Web Access features permission is set to Deny, the user will only see those features permitted for the Limited group (see Change access levels). A Deny will override any implicit allow, even for accounts that are members of administrative groups such as Team Foundation Administrators.

  5. The View instance-level information permission is also assigned to the Team Foundation Valid Users group.

Collection-level permissions

Collection-level permissions grant authorization to collection-wide tasks, which you can set for these users and groups:

  • Collection-level users and groups, such as Project Collection Administrators

  • Project-level groups that you add to a collection

  • Custom groups that you add to a collection

You can set collection-level permissions from the TWA administration page for the collection, from the Team Foundation Administration Console or using the TFSSecurity command-line tool or tf command-line tool. All permissions are scoped to the specific collection for which they are set.

Permission name

TFSSecurity Action

TFSSecurity Namespace

Description

Project Collection Service Accounts

Project Collection Build Service Accounts

Project Collection Build Administrators

Project Collection Administrators (Note 1)

Administer build resource permissions

AdministerBuildResourcePermissions

BuildAdministration

Can modify permissions for build resources.

check mark

check mark check mark

Administer Project Server integration

AdministerProjectServer

ProjectServerAdministration

Can configure the integration of TFS and Project Server to enable data synchronization between the two server products.

check mark

check mark

Administer shelved changes

AdminShelvesets

tf: AdminShelvesets

VersionControlPrivileges

Can delete shelvesets created by other users.

check mark check mark

check mark

Administer workspaces

AdminWorkspaces

tf: AdminWorkspaces

VersionControlPrivileges

Can create workspaces for other users and delete workspaces created by other users.

check mark check mark

check mark

Alter trace settings

DIAGNOSTIC_TRACE

Collection

Can change the trace settings for gathering more detailed diagnostic information about TFS Web services.

check mark

Create a workspace (Note 2)

tf: CreateWorkspace

VersionControlPrivileges

Can create a version control workspace.

check mark

check mark check mark

Create new projects (Note 3)

CREATE_PROJECTS

Collection

Can create projects in the team project collection.

check mark

Delete team project (Note 4)

Delete

Project

Can delete team projects.

check mark

Edit collection-level information (Note 5)

GENERIC_WRITE

tf: AdminConfiguration

tf: AdminConnections

Collection

VersionControlPrivileges

Can add users and groups, and edit collection-level permissions for users and groups.

check mark

check mark

Make requests on behalf of others

Impersonate

Server

Can perform operations on behalf of other users or services. Assign only to service accounts.

check mark

Manage build resources

ManageBuildResources

BuildAdministration

Can manage build computers, build agents, and build controllers.

check mark check mark check mark check mark

Manage process template

MANAGE_TEMPLATE

Collection

Can download, create, edit, and upload process templates..

check mark

Manage test controllers

MANAGE_TEST_CONTROLLERS

Collection

Can register and de-register test controllers.

check mark

Trigger events (Note 6)

TRIGGER_EVENT

Collection

Can trigger project alert events within the collection. Assign only to service accounts.

check mark

check mark

Use build resources

UseBuildResources

BuildAdministration

Can reserve and allocate build agents. Assign only to service accounts for build services.

check mark check mark

check mark

View build resources

ViewBuildResources

BuildAdministration

Can view, but not use, build controllers and build agents that are configured for the collection.

check mark check mark check mark check mark

View collection-level information

GENERIC_READ

Collection

Can view collection-level group membership and permissions.

check mark check mark check mark check mark

View system synchronization information

SYNCHRONIZE_READ

Collection

Can call the synchronization application programming interfaces. Assign only to service accounts.

check mark

check mark

Notes:

  1. In addition, the following default assignments are made to these TFS groups:

    • Project Collection Valid Users Group: Create a workspace, View build resources, and View collection-level information.

    • Project Collection Proxy Service Accounts: Create a workspace, View build resources, and View collection-level information.

    • Project Collection Test Service Accounts: Create a workspace, Manage test controllers, View build resources, and View collection-level information.

  2. The Create a workspace permission is granted to all users as part of their membership within the Project Collection Valid Users group.

  3. Additional permissions may be required depending on your deployment. Also, you must run Visual Studio or Team Explorer as an administrator to successfully complete the Create a New Team Project Wizard.

  4. Deleting a team project will delete all data that is associated with the project. You cannot undo the deletion of a team project except by restoring the collection to a point before the project was deleted.

  5. Edit collection-level information includes the ability to perform these tasks for all team projects defined in a collection:

    • Add and administer teams and all team-related features

    • Create and modify areas and iterations

    • Edit check-in policies

    • Edit shared work item queries

    • Edit project-level and collection-level permission ACLs

    • Create and modify global lists

    • Edit event subscriptions (email or SOAP) on project or collection-level events.

    When you set Edit collection-level information to Allow through TWA, users can add or remove collection-level TFS groups and implicitly allows these users to modify version control permissions. To grant all these permissions at a command prompt, you must use the tf.exe Permission command to grant the AdminConfiguration and AdminConnections permissions, in addition to GENERIC_WRITE.

  6. Users with this permission can’t remove built-in collection-level groups such as Project Collection Administrators.

  7. Adding this permission to other users has the potential to allow denial-of-service attacks.

Project, test, and object-level permissions

Project-level permissions are specific to a single project's users and groups. Within a project, you can set permissions on the objects created for that project, such as areas, iterations, source control folders, queries and query folders, and build definitions. You can set project and object-level permissions for users and groups that you add to a team project or collection.

Many default permissions are assigned to these built-in project-level and collection-level groups:

  • Project-level groups: Builders, Contributors, Project Administrators, and Readers

  • Collection-level groups: Project Collection Administrators, Project Collection Build Service Accounts, Project Collection Proxy Service Accounts, and Project Collection Test Service Accounts

Project and test-level permissions

You can set project-level permissions from the TWA administration page for the project or by using the TFSSecurity command line tool. All project-level permissions authorize users for the specific team project for which they are set.

Permission Name

TFSSecurity Action

TFSSecurity Namespace

Description

Build Administrators, Contributors, and Teams

Project Administrators (Note 1)

Create tag definition

Create

Tagging

Can add tags through a work item form.

check mark check mark

Create test runs

PUBLISH_TEST_RESULTS

Project

Can add and remove test results and add or modify test runs.

check mark check mark

Delete team project

DELETE

Project

Can delete the team project from TFS.

check mark

Delete test runs

DELETE_TEST_RESULTS

Project

Can delete a scheduled test.

check mark check mark

Edit project-level information (Note 2)

GENERIC_WRITE

Project

Can edit project-level permissions for users and groups.

check mark

Manage test configurations

MANAGE_TEST_CONFIGURATIONS

Project

Can create and delete test configurations.

check mark check mark

Manage test environments

MANAGE_TEST_ENVIRONMENTS

Project

Users who have this permission can create and delete test environments.

check mark check mark

View project-level information

GENERIC_READ

Project

Can view project-level group membership and permissions.

check mark check mark

View test runs

VIEW_TEST_RESULTS

Project

Can view test plans under the team project area path.

check mark check mark

Notes:

  1. In addition, the following default assignments are made to these TFS groups:

    • Readers: Create tag definition, View project-level information, and View test runs.

    • Project Collection Administrators: Same permissions as Project Administrators, except for Delete test runs.

    • Project Collection Build Administrators: Same permissions as Project Administrators, except for Delete test runs.

    • Project Collection Build Service Accounts: Create test runs, Manage test configurations, Manage test environments, View project-level information, View test runs.

    • Project Collection Test Service Accounts: Create test runs, Manage test configurations, Manage test environments, View project-level information.

  2. Edit project-level information includes the ability to perform these tasks for the team project:

    • Add and administer teams and all team-related features

    • Create and modify areas and iterations

    • Edit check-in policies

    • Edit shared work item queries

    • Edit project-level permission ACLs

    • Create and modify global lists

    • Edit event subscriptions (email or SOAP) on project-level events.

Build-level permissions

You can set build-level permissions for all builds or for a build definition from the context menu for the build definition in TWA or Team Explorer, or by using the TFSSecurity command line tool.

Permission name (UI)

TFSSecurity Action

TFSSecurity Namespace

Description

Contributors

Build Definition Authors or Builders

Build Administrators

Project Administrators (Note 1)

Administer build permissions

AdministerBuildPermissions

Build

Can administer the build permissions for other users.

check mark

Delete build definition

DeleteBuildDefinition

Build

Can delete build definitions for this project.

check mark check mark check mark

Delete builds

DeleteBuilds

Build

Can delete a completed build.

check mark check mark check mark

Destroy builds

DestroyBuilds

Build

Can permanently delete a completed build.

check mark check mark

Edit build definition (Note 2)

EditBuildDefinition

Build

Can create and modify build definitions for this project.

check mark check mark check mark

Edit build quality

EditBuildQuality

Build

Can add information about the quality of the build through Team Explorer or Team Web Access.

check mark

check mark check mark

Manage build qualities

ManageBuildQualities

Build

Can add or remove build qualities.

check mark check mark

Manage build queue

ManageBuildQueue

Build

Can cancel, re-prioritize, or postpone queued builds.

check mark check mark

Override check-in validation by build (Note 3)

OverrideBuildCheckInValidation

Build

Can commit a changeset that affects a gated build definition without triggering the system to shelve and build their changes first.

Queue builds

QueueBuilds

Build

Can put a build in the queue through the interface for Team Foundation Build or at a command prompt. They can also stop the builds that they have queued. 

check mark check mark check mark check mark

Retain indefinitely

RetainIndefinitely

Build

Can mark a build so that it will not be automatically deleted by any applicable retention policy.

check mark check mark

Stop builds

StopBuilds

Build

Can stop any build that is in progress, including builds queued and started by another user.

check mark check mark

Update build information

UpdateBuildInformation

Build

Can add build information nodes to the system, and can also add information about the quality of a build. Assign only to service accounts.

View build definition

ViewBuildDefinition

Build

Can view the build definitions that have been created for the team project.

check mark check mark check mark check mark

View builds

ViewBuilds

Build

Can view the queued and completed builds for this team project.

check mark check mark check mark check mark

Notes:

  1. In addition, the following default assignments are made to these built-in groups:

    • Readers: View build definition and View builds.

    • Project Collection Administrators: All permissions except for Update build information.

    • Project Collection Build Administrators: All permissions except for Override check-in validation by build and Update build information..

    • Project Collection Build Service Accounts: Edit build quality, Manage build queue, Update build information, Override check-in validation by build, Queue builds, View build definitions, and View builds.

    • Project Collection Test Service Accounts: Update build information, View build definitions, and View builds.

  2. You turn Inheritance Off for a build definition when you want to control permissions for specific build definitions.

    When inheritance is On, the build definition respects the build permissions defined at the project level for a group or user. For example, a custom Build Managers group has permissions set to manually queue a build for project Fabrikam. Any build definition with inheritance On for project Fabrikam would allow a member of the Build Managers group the ability to manually queue a build.

    However, by turning Inheritance Off for project Fabrikam, you can set permissions that only allow Project Administrators to manually queue a build for a specific build definition. This would then allow me to set permissions for that build definition specifically.

  3. Assign the Override check-in validation by build permission only to service accounts for build services and to build administrators who are responsible for the quality of the code. For more information, see Check in to a folder that is controlled by a gated check-in build process.

Work item query permissions

You can set work item query permissions from the shortcut menu of Shared Queries from TWA or Team Explorer or by using the TFSSecurity command line tool. All permissions are scoped to the specific query or query folder for which they are set.

Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the project. To create query charts you need Advanced access.

Permission name

TFSSecurity Action

TFSSecurity Namespace

Description

Readers, Contributors, Build Administrators

Creator Owners, Project Administrators, Project Collection Administrators

Contribute

CONTRIBUTE

WorkItemQueryFolders

Can view and modify this query or query folder.

check mark

Delete

DELETE

WorkItemQueryFolders

Can delete a query or query folder and its contents.

check mark

Manage Permissions

MANAGEPERMISSIONS

Can manage the permissions for this query or query folder.

check mark

Read

READ

WorkItemQueryFolders

Can view and use the query or the queries in a folder, but cannot modify the query or query folder contents.

check mark check mark

FullControl

WorkItemQueryFolders

Can view, edit, delete, and manage permissions for a query or query folder and its contents.

check mark

Tagging permissions

Tags provide a quick way of grouping or categorizing work items. Tagging permissions are available with on-premises TFS deployments with TFS 2013.2 or later versions installed. You can set the Create tag definition from the TWA administration Security page. To set all remaining permissions, use the TFSSecurity command line tool.

Permission name

TFSSecurity Action

TFSSecurity Namespace

Description

Readers

Contributors

Project Administrators (Note 1)

Create tag definition (Note 2)

CREATE

Tagging

Can create new tags and apply them to work items. Users without this permission can only select from the existing set of tags for the team project.

check mark check mark

Delete tag definition (Note 3, 4)

DELETE

Tagging

Can remove a tag from the list of available tags for that project.

check mark

Enumerate tag definition (Note 4, 5)

ENUMERATE

Tagging

Can view a list of tags available for the work item within the team project. Users without this permission will not have a list of available tags from which to choose in the work item form or in the query editor.

check mark check mark check mark

Update tag definition (Note 4)

UPDATE

Tagging

Can rename a tag by using the REST API.

check mark check mark

Notes:

  1. In addition, the Project Collection Service Accounts group has all tagging permissions explicitly assigned.

  2. Readers and Contributors inherit the Create tag definition permission as it is set explicitly to Allow for the Project Valid Users group.

    Although the Create tag definition permission appears in the security settings at the team project level, tagging permissions are actually collection-level permissions that are scoped at the project level when they appear in the user interface. To scope tagging permissions to a single team project when using the TFSSecurity command, you must provide the GUID for the project as part of the command syntax. Otherwise, your change will apply to the entire team project collection. Keep this in mind when changing or setting these permissions.

  3. There is no UI support to delete a tag. To delete a tag, remove the assignments that are associated with the tag. TFS automatically deletes unassigned tags after 3 days of non-use.

  4. Does not appear in the UI; can only be set by using the TFSSecurity command.

  5. The View project-level information set to Allow for Readers and Contributors implicitly allows users in these groups to view existing tags (Enumerate tag definition permission).

Area-level permissions for work item tracking

Area-level permissions grant or restrict access to work items defined for a project based on their location with their area tree hierarchy.

You can define and set area-level permissions from the TWA administration page for Areas or by using the TFSSecurity command line tool. All permissions are scoped to the specific area-path for which they are set.

Permission name

TFSSecurity Action

TFSSecurity Namespace

Description

Contributors

Build Administrators

Project Collection Build Service Accounts (Note 1)

Create child nodes (Note 2)

CREATE_CHILDREN

CSS

Can create area nodes. Users who have both this permission and the Edit this node permission can move or re-order any child area nodes.

Delete this node (Note 2)

DELETE

CSS

Users who have both this permission and the Edit this node permission for another node can delete area nodes and reclassify existing work items from the deleted node. If the deleted node has child nodes, those nodes are also deleted.

Edit this node (Note 2)

GENERIC_WRITE

CSS

Can set permissions for this node and rename area nodes.

Edit work items in this node (Note 3)

WORK_ITEM_WRITE

CSS

Can edit work items in this area node.

check mark check mark check mark

Manage test plans (Note 4)

MANAGE_TEST_PLANS

CSS

Can modify test plan properties such as build and test settings.

check mark check mark

Manage test suites (Note 4)

MANAGE_TEST_SUITES

CSS

Can create and delete test suites, add and remove test cases from test suites, change test configurations associated with test suites, and modify suite hierarchy (move a test suite).

check mark check mark

View permissions for this node

GENERIC_READ

CSS

Can view the security settings for this node.

check mark check mark check mark

View work items in this node (Note 5)

WORK_ITEM_READ

CSS

Can view, but not change, work items in this area node.

check mark check mark check mark

Notes:

  1. In addition, the following default assignments are made to these built-in groups:

    • Readers: View permissions for this node and View-only permissions.

    • Project Collection Test Service Accounts: View-only permissions.

    • Team Foundation Administrators, Project Collection Administrators, and Project Administrators: All CSS permissions. Any user or group that has Edit instance-level information, Edit collection-level information, or Edit project-level information permissions can create and manage area nodes.

    • Members of the Project Collection Valid Users, Project Valid Users, or any user or group that has View collection-level information or View project-level information can view permissions of any area node.

  2. Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.

  3. Consider adding this permission to any manually added users or groups that may need to edit work items under the area node.

  4. Manage test suites permission was added with the TFS 2013.3 update. Consider adding these permissions to any manually added users or groups that may need to manage test plans or test suites under this area node.

  5. If you set the View work items in this node to Deny, the user will not be able to see any work items in this area node. A Deny will override any implicit allow, even for accounts that are members of administrative groups such as Team Foundation Administrators.

Iteration-level permissions for work item tracking

Iteration-level permissions grant or restrict access to create and manage iteration paths.

You can set iteration-level permissions for users and groups that you add to a team project or collection using the TWA administration page for Iterations or the TFSSecurity command line tool. All permissions are scoped to the specific iteration-path for which they are set.

Some work item tracking operations require multiple permissions. For example, you need multiple permissions to delete a node.

Consider granting team administrators, scrum masters, or team leads permissions to create, edit, or delete nodes.

Permission name

TFSSecurity Action

TFSSecurity Namespace

Description

Project Administrators (Note 1)

Create child nodes (Note 2)

CREATE_CHILDREN

Iteration

Can create iteration nodes. Users who have both this permission and the Edit this node permission can move or re-order any child iteration nodes.

check mark

Delete this node (Note 2)

DELETE

Iteration

Users who have both this permission and the Edit this node permission for another node can delete iteration nodes and reclassify existing work items from the deleted node. If the deleted node has child nodes, those nodes are also deleted.

check mark

Edit this node (Note 2)

GENERIC_WRITE

Iteration

Can set permissions for this node and rename iteration nodes.

check mark

View permissions for this node (Note 3)

GENERIC_READ

Iteration

Can view the security settings for this node.

check mark

Notes:

  1. Team Foundation Administrators and Project Collection Administrators are granted all Iteration permissions. Any user or group that has Edit instance-level information, Edit collection-level information, or Edit project-level information permissions can create and manage iteration nodes.

  2. Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.

  3. Members of the Project Collection Valid Users, Project Valid Users, or any user or group that has View collection-level information or View project-level information can view permissions of any iteration node.

Team Foundation Version Control (TFVC) permissions

You can set permissions on TFVC source code files and folders from the context menu for the file or folder definition in TWA or Team Explorer, or by using the tf permission command line tool. These permissions appear only for a team project set up to use TFVC as the source control system.

In version control permissions, explicit deny takes precedence over administrator group permissions.

Permission name

TFSSecurity Action and tfperm

TFSSecurity Namespace

Description

Contributors

Build Administrators

Project Collection Build Service Accounts

Project Administrators (Note 1)

Administer labels

tf: LabelOther

VersionControlItems

Can edit or delete labels created by another user.

check mark

Check in (Note 2)

tf: Checkin

VersionControlItems

Can check in items and revise any committed changeset comments. Pending changes are committed at check-in.

check mark check mark check mark check mark

Check in other users' changes

tf: CheckinOther

VersionControlItems

Can check in changes that were made by other users. Pending changes are committed at check-in.

check mark check mark

Check out (Note 2)

tf: PendChange

VersionControlItems

Can check out and make a pending change to items in a folder. Examples of pending changes include adding, editing, renaming, deleting, undeleting, branching, and merging a file. Pending changes must be checked in, so users will also need the Check in permission to share their changes with the team.

check mark check mark check mark check mark

Label

tf: Label

VersionControlItems

Can label items.

check mark check mark check mark check mark

Lock

tf: Lock

VersionControlItems

Can lock and unlock folders or files.

check mark check mark check mark check mark

Manage branch

tf: ManageBranch

VersionControlItems

Can convert any folder under that path into a branch, and also take the following actions on a branch: edit its properties, re-parent it, and convert it to a folder.Users who have this permission can branch this branch only if they also have the Merge permission for the target path. Users cannot create branches from a branch for which they do not have the Manage Branch permission.

check mark check mark

Manage permissions (Note 3)

tf: AdminProjectRights

VersionControlItems

Can manage other users' permissions for folders and files in version control.

check mark

Merge (Note 4)

tf: Merge

VersionControlItems

Can merge changes into this path.

check mark check mark check mark check mark

Read

tf: Read

VersionControlItems

Can read the contents of a file or folder. If a user has Read permissions for a folder, the user can see the contents of the folder and the properties of the files in it, even if the user does not have permission to open the files.

check mark check mark check mark check mark

Revise other users' changes (Note 5)

tf: ReviseOther

VersionControlItems

Can edit the comments on checked-in files, even if another user checked in the file.

check mark

Undo other users' changes Merge (Note 5)

tf: UndoOther

VersionControlItems

Can undo a pending change made by another user.

check mark

Unlock other users' changes (Note 5)

tf: UnlockOther

VersionControlItems

Can unlock files locked by other users.

check mark

Notes:

  1. In addition, all permissions are set to Inherited allow for Project Collection Administrators and Project Collection Service Accounts.

    Readers group is assigned view-only permissions: Read.

  2. Consider adding these permissions to any manually added users or groups that contributes to the development of the project; any users who should be able to check in and check out changes, make a pending change to items in a folder, or revise any committed changeset comments.

  3. Consider adding this permission to any manually added users or groups that contributes to the development of the project and that must be able to create private branches, unless the project is under more restrictive development practices.

  4. Consider adding this permission to any manually added users or groups that contribute to the development of the project and that must be able to merge source files, unless the project is under more restrictive development practices.

  5. Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the project and that might or must change the comments on checked-in files, even if another user checked in the file.

Git repository permissions

You can set permissions on a Git project, repository, or branch from the context menu or from the administration page in TWA, or by using the TFSSecurity command line tool. These permissions appear only for a team project set up to use Git as the source control system.

You can set all permissions for a project or repository. You can set Administer, Contribute, and Rewrite and destroy history (force push) permissions for a branch. Repositories and branches inherit permissions from assignments made at the project level.

By default, the project-level and collection level Readers groups have only Read permissions.

Permission name

TFSSecurity Action

TFSSecurity Namespace

Description

Contributors

Build Administrators

Project Administrators (Note 1)

Administer (Note 2)

Administer

GitRepositories

Can rename the repository, add additional repositories, verify the database, and set permissions for the branch. Users who have this permission can delete the repository if they also have the Force permission.

At the branch level, can set permissions for the branch and delete the branch.

check mark

Branch Creation

CreateBranch

GitRepositories

Can publish branches in the repository. Lack of this permission does not limit users from creating branches in their local repository; it merely prevents them from publishing local branches to the server.  When a user creates a new branch on the server, they have Administer, Contribute, and Force permissions for that branch by default.

check mark check mark check mark

Contribute

GenericContribute

GitRepositories

Can push their changes to the repository.

At the branch level, can push their changes to the branch.

check mark check mark check mark

Note Management

ManageNote

GitRepositories

Can push and edit Git notes to the repository.  They can also remove notes from items if they have the Force permission.  See this topic for more details on notes.

check mark check mark check mark

Read

GenericRead

GitRepositories

Can clone, fetch, pull, and explore the contents of the repository, but cannot push any changes they make to the repository.

check mark check mark check mark

Rewrite and destroy history (force push)

ForcePush

GitRepositories

Can force an update, which can overwrite or discard commits from any user. Deleting commits changes the history. Without this permission, users cannot discard their own changes. Rewrite and destroy history is also required to delete a branch.

Because Rewrite and destroy history enables users to change the history or remove a commit from history, users who have this permission can delete a change and its history from the server. They can also modify the commit history of the server repository.

At the branch level, can rewrite and destroy history of the branch.

Tag Creation

CreateTag

GitRepositories

Can push tags to the repository, and can also edit or remove tags from items if they have the Force permission.

check mark check mark check mark

Notes:

  1. For Project Collection Administrators and Project Collection Service Accounts, all permissions are set to Inherited allow.

    Readers and Project Collection Build Service Accounts groups are assigned view-only permissions: Read.

  2. Consider adding all permissions to any manually added users or groups that contribute to the development of the project.

Lab Management permissions

Visual Studio Lab Management permissions are specific to virtual machines, environments, and other resources. In addition, the creator of an object in Lab Management is automatically granted all permissions on that object. You can set these permissions by using the TFSLabConfig permissions command-line tool.

By default, the project-level and collection level Readers groups have only View lab resources (Read) permissions.

Permission name

TFSLabConfigperm

Description

Contributors (Note 1)

Project Administrators

Project Collection Build Service

Team Foundation Administrators, Project Collection Administrators

Delete Environment and Virtual Machines

Delete

Can delete environments and templates. The permission is checked for the object that is being deleted.

check mark

check mark

Delete Lab Locations

DeleteLocation

Can delete the locations for Lab Management resources, which include collection host groups, collection library shares, project host groups, and project library shares. To delete a location, you must have the Delete Lab Location permission for that location.

check mark

check mark

Edit Environment and Virtual Machines

Edit

Can edit environments and templates. The permission is checked for the object that is being edited.

check mark check mark check mark check mark

Environment Operations

EnvironmentOps

Can start, stop, pause, and manage snapshots, in addition to performing other operations on an environment.

check mark

check mark

Import Virtual Machine

Create

Can import a virtual machine from a VMM library share.This permission differs from Write because it only creates an object in Lab Management and does not write anything to the Virtual Machine Manager host group or library share.

check mark check mark

check mark

Manage Child Permissions

ManageChildPermissions

Can change the permissions of all the child Lab Management objects. For example, if a user has Manage Child Permission for a team project host group, the user can change permissions for all the environments under that team project host group.

check mark

check mark

Manage Lab Locations

ManageLocation

Can edit the locations of Lab Management resources, which include collection host groups, collection library shares, project host groups, and project library shares. To edit a specific location, you must have the Manage Lab Location permission for that location. This permission for collection-level locations (collection host groups and collection library shares) also allows you to create project-level locations (project host group and project library share).

check mark

check mark

Manage Permissions

ManagePermissions

Can modify the permissions for a Lab Management object. This permission is checked for the object whose permissions are being modified.

check mark

Manage Snapshots

ManageSnapshots

Can perform all snapshot management tasks for an environment, which include taking a snapshot, reverting to a snapshot, renaming a snapshot, deleting a snapshot, and reading a snapshot.

check mark check mark check mark check mark

Pause Environment

Pause

Can pause an environment.

check mark check mark check mark check mark

Start

Start

Can start an environment.

check mark check mark check mark check mark

Stop

Stop

Can stop an environment.

check mark check mark

check mark

View Lab Resources

Read

Can view information for the various Lab Management resources, which include collection host groups, project host groups, and environment. To view information about a specific lab resource, you must have the View Lab Resources permission for that resource.

check mark check mark check mark check mark

Write Environment and Virtual Machines

Write

Can create environments for a project host group. Users who have this permission for a project library share can store environments and templates.

check mark check mark check mark check mark

Notes:

  1. The Readers group is assigned view-only permissions: Read.

Release Management permissions

In Release Management, you can assign permissions based on the role assigned to a user, explicit functional permissions assigned to groups, or permissions assigned to specific instances of a release object. In addition, you can assign approvers and validators to specific stages within a release path to ensure that the applications being deployed meet quality standards.

  • Role based: The two roles are Release Manager and Service User. Release Managers can manage all functions, regardless of the groups they are linked to. Service User corresponds to a service account role. To limit a user’s access, do not assign them to any role. Instead, have them inherit the permissions assigned to the group they are linked to.

  • Group: To restrict access to specific functional areas, you assign the permissions allowed by that group. Members of that group inherit the permissions assigned to the group. Restricting access requires that you change the permissions granted to the Everyone group, which by default has all permissions.

  • Object: In addition to roles and groups, you can restrict access to edit, view, and manage security of release paths and release templates. You do this through the Security tab on the release path and through the Properties page for a release template.

  • Approvers and Validators: Approvers and validators must sign off at each step or stage of a release. You assign approvers and validators when you configure a release path. All approvers and validators must be added as users or a member of a group in Release Management.

Release Management defines a single default group, Everyone, to which all accounts that you add to Release Management belong. In addition, specific permissions are allocated to the Release Manager and Service User roles.

You manage Release Management permissions from the Release Management client. You can set these permissions by opening the sub-menu listed in the Where set column. To learn more about how to set these permissions, see Add users and groups and control access to Release Management. To install Release Management, go here.

Permission name or user role

Where set

Description

Everyone

Release Manager Role

Service User role

Release Manager

Administration > My Profile and New User page

Can administer the Release Management server, manage the connection between TFS and Release Management, and manage the following objects:

  • Release paths and stage information defined in a release path.

  • Release templates, including adding custom tools and actions and deployment sequence and configuration variables for all stages defined in a release template.

  • Security for all functional areas.

Consider adding: Users who will administer the Release Management server.

check mark

Service User

Administration > My Profile and New User page

Can manage deployments or web application pools.

Consider adding: Service account identities assigned to run server application pools, deployment agent’s Windows Service, and Release Management monitoring of Windows Services.

check mark

View

Configure Apps > Release Template > Properties

Configure Paths > Release Paths

Can view release templates or release paths and selectively assign view access to specific release templates and release paths to specific users.

Consider adding: Users or groups that need to view specific release templates or release paths, but not edit them.

check mark check mark check mark

Edit

Configure Apps > Release Template > Properties

Configure Paths > Release Paths

Can edit release templates or release paths and choose which users can edit specific release templates and release paths to specific users.

Consider adding: Users or groups that need to edit specific release templates or release paths.

check mark check mark check mark

Can Release

Configure Apps > Release Template > Properties

Can initiate a release and specify which users can initiate a release from those release templates that they can view.

Consider adding: Users or groups that will initiate a release. With this permission, you can specify which users can initiate a release from those release templates that they can view.

check mark check mark check mark

Manage Security

Configure Apps > Release Template > Properties

Configure Paths > Release Paths

Can manage which groups have permissions to view, edit, or manage release templates or release paths.

Consider adding: Users or groups that will manage which groups have permissions to view, edit, or manage release templates or release paths. With this permission, creators of release templates and release paths can control who can view, edit, or release specific templates or paths.

check mark check mark check mark

Can Create Release Template

Configure Apps > Release Template

Can define release templates.

Without this permission, the New button on the Configure Apps > Release Template tab is hidden.

Consider adding: Users or groups that need to create, start, or approve a release.

check mark check mark check mark

Can Create Release Path

Configure Paths > Release Paths

Can define the stages, approval process, and security of release paths.

Without this permission, the New button on the Configure Paths > Release Paths tab is hidden.

Consider adding: Users or groups that need to manage the release configuration used in deploying applications.

check mark check mark check mark

Can Manage Environment

Configure Paths > Environments

Can define the stages that comprise a release path and the servers and security for each stage.

Without this permission, the Configure Paths > Environments tab is hidden.

Consider adding: Users or groups that need to manage the servers and environments used to define the release paths.

check mark check mark check mark

Can Manage Server

Configure Paths > Server

Can define the release paths for deploying applications in your system. This permission supports access to defining the servers use to deploy applications to test, stage, and production servers.

Without this permission, the Configure Paths > Server tab is hidden.

Consider adding: Users or groups that will define the release paths for deploying applications in your system. This permission supports access to defining the servers used to deploy applications to test, stage, and production servers.

check mark check mark check mark

Can Manage Inventory

Inventory > Actions and Tools

Can define custom tools or actions for deploying applications in your system. With this permission they can view, edit, and create actions and tools. See Release actions to deploy an app for Release Management.

Without this permission, the Inventory tab is hidden.

Consider adding: Users or groups that will define custom tools or actions for deploying applications in your system. With this permission they can view, edit, and create actions and tools used in deploying applications.

check mark check mark check mark

Can Use Custom Tool in Actions and Components

Configure Apps > Component> Deployment

Configure Apps > Release Template > Component > Deployment

Can edit the Command and Arguments fields when No Tool is selected.

Without this permission, users cannot edit these fields.

Consider adding: Users or groups that will define release paths or release templates or who will initiate releases. This allows them to edit the Command and Arguments fields when No Tool is selected.

check mark check mark check mark

Edit Values and Target Servers

Configure Apps > Release Template

Can edit deployment sequence and configuration variables for specific releases or stages.

Without this permission, stage information is read-only.

Consider adding: Users or groups that will define release paths or release templates or who will initiate releases. This allows them to edit deployment sequence and configuration variables for specific releases or stages.

check mark check mark check mark

Edit Approvals and Environment

Configure Paths > Release Path > Stages

Can edit approvals and environments for a specific stage.

Without this permission, stage information is read-only.

Consider adding: Users or groups that will define release paths or release templates. This allows them to edit approvals and environments for a specific stage.Without this permission, stage information is read-only.

check mark check mark check mark

Q & A

Q: What’s the difference between permissions and access levels?

A: Certain features in TFS are only available to users who have the appropriate licensing level for those features. Access to those features is not controlled by permissions but by membership in licensing groups for Team Web Access. See Change access levels.

Q: What permissions are assigned to team administrators?

A: Team administrators are granted several role-based permissions that are described here.

Q: What permissions are associated with Alerts?

A: There are no UI permissions associated with alerts that you can subscribe to through TWA.

By default, all Contributors can subscribe to alerts for themselves. Project Collection Administrators and Project Administrators or users or members of groups who have either the Edit collection-level information or Edit project-level information can set alerts for others or for a team.

You can manage alert permissions using TFSSecurity at the collection-level. The Team Foundation Event service is designed to be flexible and extensible.

TFSSecurity Action

TFSSecurity Namespace

Description

Project Collection Administrators and Project Collection Service Accounts

CREATE_SOAP_SUBSCRIPTION

EventSubscription

Can create a SOAP-based web service subscription.

check mark

GENERIC_READ

EventSubscription

Can view subscription events defined for a team project.

check mark

GENERIC_WRITE

EventSubscription

Can create alerts for other users or for a team.

check mark

UNSUBSCRIBE

EventSubscription

Can unsubscribe from an event subscription.

check mark

Q: What additional features or tools reference groups?

A: These features reference built-in and custom (ones that you create) TFS groups:

Q: What is a Valid User? How are Valid User groups populated?

A: When you add accounts of users directly to a TFS group or through a Windows group, they are automatically added to one of the valid user groups.

  • Server\Team Foundation Valid Users: All members added to server-level groups.

  • ProjectCollectionName\Project Collection Valid Users: All members added to project-collection level groups.

  • TeamProjectName\Project Valid Users: All members added to project-level groups.

The default permissions assigned to these groups are primarily limited to read access, such as View build resources, View project-level information, and View collection-level information.

This means that all users that you add to one team project can view the objects in other team projects within a collection. If you need to restrict view access, then you can set restrictions through the area path node. For additional methods, see Restrict access to functions and tasks.

If you remove or set the View instance-level information permission to Deny for one of the Valid Users groups, no users in the group will be able to access the team project, collection, or deployment, depending on the group you set.

In addition, the VALIDUSER element can be used to allow or restrict access for work item tracking.

Q: How do I manage permissions to access reports or the project portal?

A: For information about how to set permissions in Reporting Services and SharePoint Products for users in TFS, see Set administrator permissions for team project collections, and Set administrator permissions for Team Foundation Server.

For step-by-step examples of how to create custom groups, configure permissions to control access to resources, and other options, see Restrict access to functions and tasks.