Skip to content

Latest commit

 

History

History
1972 lines (1746 loc) · 80.5 KB

permissions.md

File metadata and controls

1972 lines (1746 loc) · 80.5 KB
Raw
title titleSuffix description ms.prod ms.technology ms.assetid toc ms.topic ms.manager ms.author author ms.date monikerRange
Permissions and groups reference
VSTS & TFS
Comprehensive reference of built-in (default) security groups, and permissions defined in Visual Studio Team Services and Team Foundation Server
devops
devops-security
169E817F-B297-4461-B359-27C78D4A8A7D
show
reference
douge
kaelli
KathrynEE
02/12/2018
>= tfs-2013

Permissions and groups in VSTS and TFS

[!INCLUDE temp]

This topic provides a comprehensive reference for each built-in group and permission. To learn how to add users to a group or set a specific permission that you can manage through the web portal, see the following resources:

::: moniker range="vsts"

[!div class="mx-tdBreakAll"]

Users and groups DevOps permissions Agile/Work tracking permissions
- Add users to an administrator role
- Add users to an account
- Add users to a team project or a team
- Make a user a team admin

Miscellaneous
- README & Wiki		 - Git branch
- Git repositories
- TFVC
- Builds
- Releases
- Approvals and approvers
- Task groups
- Variable groups
- Role-based resources		 - Area and iteration paths
- Work item query and folder
- Plan permissions
- Dashboard permissions
- Analytics service
- Analytics views
- Customize process

::: moniker-end

::: moniker range=">= tfs-2013 <= tfs-2018"

[!div class="mx-tdBreakAll"]

Users and groups DevOps permissions Agile/Work tracking permissions
- Add users to an administrator role
- Add users to a team project or a team
- Make a user a team admin

Miscellaneous
- README & Wiki
- SharePoint (TFS)
- SQL Server Reports (TFS)		 - Git branch
- Git repositories
- TFVC
- Builds
- Releases
- Approvals and approvers
- Task groups
- Variable groups
- Role-based resources		 - Area and iteration paths
- Work item query and folder
- Plan permissions
- Dashboard permissions

::: moniker-end

Note

The images you see from your web portal may differ from the images you see in this topic. These differences result from updates made to VSTS or your on-premises TFS. However, the basic functionality available to you remains the same unless explicitly mentioned.

Groups

Permissions can be granted directly to an individual, or to a group. Using groups can make things a lot simpler, and TFS sets up some built-in groups for that purpose. These groups and the permissions they're assigned to exist at several different levels: server (TFS deployment), team project collection, team project, and specific objects. You can also create your own groups and grant them the specific set of permissions that are appropriate for certain roles in your organization.

::: moniker range=">= tfs-2013 <= tfs-2018"

##   Server-level groups

When you install TFS, the system creates default groups that have deployment-wide, server-level permissions. You can neither remove nor delete the built-in server-level groups.

ADMIN_GROUPS_PERMISSIONS

You can't remove or delete the default server level groups.

Group name Permissions Membership
Team Foundation Administrators Has permissions to perform all operations for 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.

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

If your deployment uses SharePoint or Reporting, consider [adding the members of this group](/tfs/server/admin/add-administrator-tfs) to the Farm Administrators and Site Collection Administrators groups in SharePoint and the Team Foundation Content Managers groups in Reporting Services.
Team Foundation Proxy Service Accounts Has service level permissions for Team Foundation Server Proxy, and some TFS service level permissions.
Created when you install the TFS proxy service.
This group should contain only service accounts and not user accounts or groups that contain user accounts.
Team Foundation Service Accounts

Has 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 groupsthat contain user accounts. By default, this group is a member of Team Foundation Administrators.

If you need to add an account to this group after you install TFS, you can do so using the TFSSecurity.exe utility in the **Tools** subfolder of your TFS installation directory. The command to do this is `TFSSecurity /g+ "[TEAM FOUNDATION]\Team Foundation Service Accounts" n:domain\username /server:http(s)://tfsservername`

Team Foundation Valid Users Has permission to view instance level information.
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 known to exist in the VSTS account or TFS instance. You can't modify the membership of this group.
Project Server Integration Service Accounts Has service level permissions for the Project Server deployments that are configured for interoperation with TFS and some TFS service level permissions.
Created when you install Project Service integration.
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 Has service level permissions for the SharePoint Web applications that are configured for use with TFS and 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.

The full name of each of these groups is [Team Foundation]/{group name}. So the full name of the server level administrators group is [Team Foundation]/Team Foundation Administrators.

::: moniker-end

##   Collection-level groups

When you create a VSTS account or TFS collection, the system creates collection-level groups that have permissions in that collection. You can neither remove nor delete the built-in collection-level groups.

Groups

Group name Permissions Membership
Project Collection Administrators

Has permissions to perform all operations for the 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 CollectionName\Service Accounts group.

This group should be restricted to the smallest possible number of users who need total administrative control over the collection. For VSTS, assign to administrators who will customize work tracking.

If your deployment uses SharePoint or Reporting, consider [adding the members of this group](../security/set-project-collection-level-permissions.md) to the Site Collection Administrators group in SharePoint and the Team Foundation Content Managers groups in Reporting Services.
Project Collection Build Administrators

Has permissions to 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

Has permissions 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

Has permissions to run the proxy service for the collection.

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

Project Collection Service Accounts

Has 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 Test Service Accounts

Has test service permissions for the collection.

Limit this group to service accounts and groups that contain only service accounts.
Project Collection Valid Users

Has permissions to access team projects and view information in the collection.

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

The full name of each of these groups is [{collection name}]/{group name}. So the full name of the administrator group for the default collection is [Default Collection]/Project Collection Administrators.

##   Project-level groups

For each team project that you create, the system creates the followings team project-level groups. These groups are assigned project-level permissions.

The full name of each of these groups is [{team project name}]{group name}. For example, the contributors group for a team project called "My Project" is [My Project]/Contributors.

Group name Permissions Membership
Build Administrators Has permissions to administer build resources and build permissions for the team project. Members can manage test environments, create test runs, and manage builds.
Contributors Has permissions to contribute fully to the team 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 Has permissions to view the team project but not modify it. Assign to [stakeholders](../security/get-started-stakeholder.md) who want to be able to view work in progress.
Project Administrators Has permissions to administer all aspects of teams and team project, although they can't create team projects. Assign to users who will manage user permissions, create or edit teams, modify team settings, define area an iteration paths, or customize work item tracking.
Project Valid Users

Has permissions to access the team project.

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 team project.

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

{team name} Has permissions to contribute fully to the team 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.
You can grant permissions to administer team assets by [adding members to the team administrator role](../work/scale/add-team-administrator.md).
Add members of the team to this group.

##   Team administrator role

For each team that you add, you can assign one or more team members as administrators. The team admin role isn't a group with a set of defined permissions. Instead, the team admin role is tasked with managing team assets. To learn more, see About security roles, Team administrator role. To add a user as a team administrator, see Add a team administrator.

Note

Project Administrators can manage all team admin areas for all teams.

Permissions

The system manages permissions at different levels—server, collection, project, or object—and by default assigns them to one or more built-in groups. You manage most permissions through the web portal.

::: moniker range=">= tfs-2013 <= tfs-2018"

##   Server-level

You manage server-level permissions through the Team Foundation Administration Console or TFSSecurity command-line tool. Team Foundation Administrators are granted all server-level permissions. Other server-level groups have select permission assignments.

Permission Description
Administer warehouse

Can process or change settings for the data warehouse or SQL Server Analysis cube by using the [Warehouse Control Web Service](../report/admin/manage-reports-data-warehouse-cube.md).

Additional permissions may be required to fully process or [rebuild the data warehouse and Analysis cube](../report/admin/rebuild-data-warehouse-and-cube.md).

Create team project collection Can create and administer collections.
Delete team project collection Can delete a collection from the deployment.
Deleting a collection will not delete the collection database from SQL Server.
Edit instance-level information Can edit server level permissions for TFS users and groups, and add or remove server level groups from the collection.

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

  • Create and modify areas and iterations
  • Edit check-in policies
  • Edit shared work item queries
  • Edit team project level and collection level permission ACLs
  • Create and modify global lists
  • Edit [event subscriptions](#alerts) (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.

Make requests on behalf of others Can perform operations on behalf of other users or services. Only assign to service accounts.
Trigger events Can trigger TFS alert events. Only assign to service accounts and members of the Team Foundation Administrators group.
Use full Web Access features Can use all TFS WEB PORTAL features.
If the Use full Web Access features permission is set to Deny, the user will only see those features permitted for the **Stakeholder** group (see [Change access levels](change-access-levels.md)). A Deny will override any implicit Allow, even for accounts that are members of administrative groups such as Team Foundation Administrators.
View instance-level information Can view server level group membership and the permissions of those users.
The **View instance-level information** permission is also assigned to the Team Foundation Valid Users group.

::: moniker-end

##   Collection-level

You manage collection-level permissions through the web portal admin context or TFSSecurity command-line tool. Project Collection Administrators are granted all collection-level permissions. Other collection-level groups have select permission assignments.

Permission Description
Administer build resource permissions Can modify permissions for build resources.
Administer process permissions Can modify permissions for processes. Applies to VSTS only.
Administer Project Server integration Can [configure the integration of TFS and Project Server](../work/tfs-ps-sync/synchronize-tfs-project-server.md) to enable data synchronization between the two server products. Applies to TFS 2017 and earlier versions only.
Administer shelved changes Can delete shelvesets created by other users.
Administer workspaces Can create workspaces for other users and delete workspaces created by other users.
Alter trace settings Can change the trace settings for gathering more detailed diagnostic information about TFS Web services.
Create a workspace Can create a version control workspace.
The **Create a workspace** permission is granted to all users as part of their membership within the Project Collection Valid Users group.
Create new team projects Can create team projects in the collection.
Additional permissions may be required depending on your deployment. 
			[Create a New Team Project Wizard](../accounts/create-team-project.md).
		</blockquote>
	</td>
</tr>
<tr>
	<td id="create-process-permission">Create process</td>
	<td>
		Can [create an inherited process](../work/customize/process/manage-process.md). Applies to VSTS only.
	</td>
</tr>
<tr>
	<td id="delete-process-permission">Delete process</td>
	<td>
		Can [delete an inherited process](../work/customize/process/manage-process.md). Applies to VSTS only.
	</td>
</tr>
<tr>
	<td id="delete-team-project-permission">Delete team project</td>
	<td>
		Can [delete team projects](../accounts/delete-team-project.md).
		<blockquote>
			Deleting a team project will delete all data that is associated with the team project.
			You cannot undo the deletion of a team project except
			by restoring the collection to a point
			before the team project was deleted.
		</blockquote>
	</td>
</tr>
<tr>
	<td id="edit-collection-level-information-permission">Edit collection-level information</td>
	<td>
		Can add users and groups, and edit collection level permissions for users and groups.
		<blockquote>
			<p>
				Edit collection level information includes the ability to perform these tasks
				for all team projects defined in a collection:
			</p>

			<ul>
				<li>Add and administer teams and all team-related features</li>
				<li>Create and modify areas and iterations</li>
				<li>Edit check-in policies</li>
				<li>Edit shared work item queries</li>
				<li>Edit team project level and collection level permission ACLs</li>
				<li>Manage process templates</li>
				<li>Customize a team project or process</li>
				<li>Create and modify global lists</li>
				<li>Edit [event subscriptions](#alerts) (email or SOAP) on team project or collection level events.</li>
			</ul>

			<p>
				When you set **Edit collection-level information** to **Allow**,
				users can add or remove collection level 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.
			</p>
		</blockquote>
	</td>
</tr>
<tr>
	<td id="edit-process-permission">Edit process</td>
	<td>
		Can edit a [custom inherited process](../work/customize/process/customize-process.md). Applies to VSTS only.
	</td>
</tr>
<tr>
	<td id="make-requests-on-behalf-of-others-permission">Make requests on behalf of others</td>
	<td>
		Can perform operations on behalf of other users or services.
		Assign only to service accounts.
	</td>
</tr>
<tr>
	<td id="manage-build-resources-permission">Manage build resources</td>
	<td>Can manage build computers, build agents, and build controllers.</td>
</tr>
<tr>
	<td id="manage-process-template-permission">Manage process template</td>
	<td>
		Can download, create, edit, and upload process templates. Applies to TFS only. 
	</td>
</tr>
<tr>
	<td id="manage-test-controllers-permission">Manage test controllers</td>
	<td>Can register and de-register test controllers.</td>
</tr>
<tr>
	<td id="trigger-events-permission">Trigger events</td>
	<td>
		Can trigger team project alert events within the collection. Assign only to service accounts.
		<blockquote>
			Users with this permission can't remove built-in collection level groups
			such as Project Collection Administrators.
		</blockquote>
	</td>
</tr>
<tr>
	<td id="use-build-resources-permission">Use build resources</td>
	<td>Can reserve and allocate build agents. Assign only to service accounts for build services.</td>
</tr>
<tr>
	<td id="view-build-resources-permission">View build resources</td>
	<td>Can view, but not use, build controllers and build agents that are configured for the collection.</td>
</tr>
<tr>
	<td id="view-collection-level-information-permission">View instance-level information<br/>or View collection-level information</td>
	<td>Can view collection level group membership and permissions.
		<blockquote>
			If you set the <strong>View instance-level information</strong> permission
			to <strong>Deny</strong> or <strong>Not set</strong> for this group,
			no users will be able to access the collection.
		</blockquote></td>
</tr>
<tr>
	<td id="view-system-synchronization-information-permission">View system synchronization information</td>
	<td>Can call the synchronization application programming interfaces. Assign only to service accounts.</td>
</tr>

##   Project-level

You manage project-level permissions from the web portal admin context or using the TFSSecurity command-line tool. Project Administrators are assigned all project-level permissions. Other project-level groups are assigned a subset of these permissions.

<tr>
	<td id="permanently-delete-work-items-in-this-project-permission">Permanently delete work items in this project</td>
	<td>Can [permanently delete work items](../work/backlogs/remove-delete-work-items.md) from this project.</td>
</tr>
<tr>
	<td id="rename-team-project-permission">Rename team project</td>
	<td>Can [change the name of the team project](../accounts/rename-team-project.md).</td>
</tr>
<tr>
	<td id="view-analytics-permission">View analytics</td>
	<td>Can access data available from the [Analytics service](../report/analytics/what-is-analytics.md). For details, see [Permissions required to access the Analytics service](../report/analytics/analytics-security.md). Applies to VSTS only.</td>
</tr>
<tr>
	<td id="view-team-project-level-information-permission">View team project-level information</td>
	<td>Can view team project level group membership and permissions.</td>
</tr>
<tr>
	<td id="view-test-runs-permission">View test runs</td>
	<td>Can view test plans under the team project area path.</td>
</tr>
Permission Description
Create tag definition Can add tags through a work item form.
Create test runs Can add and remove test results and add or modify test runs.
Delete team project Can [delete the team project](../accounts/delete-team-project.md) from the collection.
Delete test runs Can delete a scheduled test.

Delete and restore work items

or Delete work items in this project

 Can [mark work items in this project as deleted](../work/backlogs/remove-delete-work-items.md).
  • For VSTS and TFS 2015.1 and later versions, the Contributors group has **Delete and restore work items** at the project-level set to "Allow" by default.
  • For TFS 2015 and earlier versions, the Contributors group has **Delete work items in this project** at the project-level set to "Not set" by default. This setting causes the Contributors group to inherit the value from the closest parent that has it explicitly set.
Edit team project-level information Can edit team project level permissions for users and groups.

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

  • Create and modify areas and iterations
  • Edit check-in policies
  • Edit shared work item queries
  • Edit team project level permission ACLs
  • Manage process templates
  • Customize a team project
  • Create and modify global lists
  • Edit [event subscriptions](#alerts) (email or SOAP) on team project level events.
Manage project properties Can provide or edit metadata for a team project. For example, a user can provide high-level information about the contents of a project. Changing metadata is supported through the [Set project properties REST API](https://www.visualstudio.com/docs/integrate/api/tfs/projects#set-project-properties).
Manage test configurations Can create and delete test configurations.
Manage test environments Users who have this permission can create and delete test environments.
Move work items out of this project Can [move a work item from one team project to another team project](../work/backlogs/remove-delete-work-items.md) within the collection. Applies to VSTS only.

::: moniker range="vsts"

##   Analytics views (object-level)

With shared Analytics views, you can grant specific permissions to view, edit, or delete a view that you create. You manage the security of Analytics views from the web portal.

 [!div class="mx-imgBorder"] Manage permissions

The following permissions are defined for each shared Analytics view. All valid users are automatically granted all permissions to manage Analytics views. Consider granting select permissions to specific shared views to other team members or security group that you create. See also, What are Analytics views?

[]
Permission Description
Delete Can delete the shared Analytics view.
Edit Can change the parameters of the shared Analytics view.
View Can view and use the shared Analytics view from Power BI desktop.

::: moniker-end

##   Build (object-level)

You manage build permissions for each build defined in the web portal or using the TFSSecurity command-line tool. Project Administrators are granted all build permissions and Build Administrators are assigned most of these permissions. You can set build permissions for all build definitions or for each build definition.

Permissions in Build follow a hierarchical model. Defaults for all the permissions can be set at the team project level and can be overridden on an individual build definition.

To set the permissions at project level for all build definitions in a project, choose Security from the action bar on the main page of Builds hub.

To set or override the permissions for a specific build definition, choose Security from the context menu of the build definition.

The following permissions are defined in Build. All of these can be set at both the levels.

Permission Description
Administer build permissions Can administer the build permissions for other users.
Delete build definition Can delete build definitions for this team project.
Delete builds Can delete a completed build. Builds that are deleted are [retained](../pipelines/policies/retention.md) in the **Deleted** tab for a period of time before they are destroyed.
Destroy builds Can permanently delete a completed build.
Edit build definition Can create and modify build definitions for this team project.

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 team project level or a group or user. For example, a custom Build Managers group has permissions set to manually queue a build for team project Fabrikam. Any build definition with inheritance On for team project Fabrikam would allow a member of the Build Managers group the ability to manually queue a build.

However, by turning Inheritance Off for team 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.

Edit build quality Can add information about the quality of the build through Team Explorer or the web portal.
Manage build qualities Can add or remove build qualities. Only applies to XAML builds.
Manage build queue Can cancel, re-prioritize, or postpone queued builds. Only applies to XAML builds./td>
Override check-in validation by build Can commit a TFVC change set that affects a gated build definition without triggering the system to shelve and build their changes first.
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. Applies to [TFVC gated check-in builds](../pipelines/build/triggers.md). This does not apply to PR builds. For more information, see [Check in to a folder that is controlled by a gated check-in build process](../tfvc/check-folder-controlled-by-gated-check-build-process.md).
Queue builds 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.
Retain indefinitely Can toggle the retain indefinitely flag on a build. This feature marks a build so that the system won't automatically delete it based on any applicable retention policy.
Stop builds Can stop any build that is in progress, including builds queued and started by another user.
Update build information 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 Can view the build definitions that have been created for the team project.
View builds Can view the queued and completed builds for this team project.

##   Git repository (object-level)

Note

These permissions have changed in TFS 2017 Update 1 and VSTS. If you are using an earlier version of TFS, see the previous list of permissions.

You manage the security of each Git repository or branch from the web portal, the TF command line tool, or using the TFSSecurity command-line tool. Project Administrators are granted most of these permissions (which appear only for a team project that's been configured with a Git repository). You can manage these permissions for all Git repositories, or for a specific Git repo.

Set permissions across all Git repositories by making changes to the top-level Git repositories entry.

Individual repositories inherit permissions from the top-level Git Repositories entry. Branches inherit permissions from assignments made at the repository level.

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

<tr>
	<td id="git-contribute-to-pull-requests-permission">Contribute to Pull Requests</td>
	<td>Can create, comment on, and vote on pull requests.</td>
</tr>

<tr>
	<td id="git-create-branch-permission">Create Branch</td>
	<td>
		Can create and 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 Contribute, Edit Policies, Force Push, Manage Permissions, and Remove Others' Locks permissions for that branch by default.
	</td>
</tr>
<tr>
	<td id="git-create-repository-permission">Create Repository</td>
	<td>
	Can create new repositories. This permission is only available from the Security dialog for the top-level **Git repositories** object. 
	</td>
</tr>
<tr>
	<td id="git-create-tag-permission">Create Tag</td>
	<td>
		Can push tags to the repository.
	</td>
</tr>
<tr>
	<td id="git-delete-repository-permission">Delete Repository</td>
	<td>
	Can delete the repository. At the top-level **Git repositories** level, can delete any repository.
	</td>
</tr>
<tr>
	<td id="git-edit-policies-permission">Edit Policies</td>
	<td>
	Can edit policies for the repository and its branches.
	</td>
</tr>
<tr>
	<td id="git-exempt-from-policy-permission">Exempt From Policy Enforcement</td>
	<td>
	Can bypass branch policies.
	</td>
</tr>
<tr>
	<td id="git-force-push-permission">Force Push (Rewrite History and Delete Branches)</td>
	<td>
	Can force an update to a branch, delete a branch, and modify the commit history of a branch. Can delete tags and notes.
	</td>
</tr>
<tr>
	<td id="git-note-management-permission">Manage Notes</td>
	<td>
		Can push and edit Git notes.  
	</td>
</tr>
	<td id="git-create-repository-permission">Manage Permissions</td>
	<td>
	Can set permissions for the repository.
	</td>
</tr>
<tr>
	<td id="git-read-permission">Read</td>
	<td>
		Can clone, fetch, pull, and explore the contents of the repository.
	</td>
</tr>
<tr>
	<td id="git-remove-others-locks-permission">Remove Others' Locks</td>
	<td>
		Can remove [branch locks](../git/lock-branches.md) set by other users.
	</td>
</tr>
<tr>
	<td id="git-rename-repository-permission">Rename Repository</td>
	<td>
		Can change the name of the repository. When set at the top-level **Git repositories** entry, can change the name of any repository.
	</td>
</tr>
Permission Description
Contribute At the repository level, can push their changes to existing branches in the repository and can complete pull requests. Users who lack this permission but who have [create branch](#git-create-branch-permission) may push changes to new branches. Does not override restrictions in place from [branch policies](../git/branch-policies.md).
At the branch level, can push their changes to the branch and lock the branch.

Note

Set permissions across all Git repositories by making changes to the top-level Git repositories entry. Individual repositories inherit permissions from the top-level Git repositories entry. Branches inherit permissions from assignments made at the repository level. By default, the team project level and collection-level Readers groups only have Read permissions.

To manage Git repo and branch permissions, see Set branch permissions.

##   TFVC (object-level)

You manage the security of each TFVC branch from the web portal or using the TFSSecurity command-line tool. Project Administrators are granted most of these permissions which appear only for a team project that's been configured to use Team Foundation Version Control as a source control system. In version control permissions, explicit deny takes precedence over administrator group permissions.

These permissions appear only for a team project set up to use Team Foundation Version Control as the source control system.

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

Permission Description
Administer labels Can edit or delete labels created by another user.
Check in Can check in items and revise any committed change set comments. Pending changes are committed at check-in.
Consider adding these permissions to any manually added users or groups that contributes to the development of the team 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 change set comments.
Check in other users' changes Can check in changes that were made by other users. Pending changes are committed at check-in.
Check out 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.
Consider adding these permissions to any manually added users or groups that contributes to the development of the team 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 change set comments.
Label Can label items.
Lock Can lock and unlock folders or files.
Manage branch 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.
Manage permissions Can manage other users' permissions for folders and files in version control.
Consider adding this permission to any manually added users or groups that contributes to the development of the team project and that must be able to create private branches, unless the team project is under more restrictive development practices.
Merge Can merge changes into this path.
Consider adding this permission to any manually added users or groups that contribute to the development of the team project and that must be able to merge source files, unless the team project is under more restrictive development practices.
Read 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.
Revise other users' changes Can edit the comments on checked-in files, even if another user checked in the file.
Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the team project and that might or must change the comments on checked-in files, even if another user checked in the file.
Undo other users' changes Merge Can undo a pending change made by another user.
Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the team project and that might or must change the comments on checked-in files, even if another user checked in the file.
Unlock other users' changes Can unlock files locked by other users.
Consider adding this permission to any manually added users or groups that are responsible for supervising or monitoring the team project and that might or must change the comments on checked-in files, even if another user checked in the file.

##   Area path (object-level)

Area path permissions grant or restrict access to branches of the area hierarchy and to the work items in those areas. You manage the security of each area path from the web portal or using the TFSSecurity command-line tool. Area permissions grant or restrict access to create and manage area paths as well as create and modify work items defined under area paths.

Members of the Project Administrators group are automatically granted permissions to manage area paths for a team project. Consider granting team administrators or team leads permissions to create, edit, or delete area nodes.

Note

Multiple teams may contribute to a team project. When that's the case, you can set up teams that are associated with an area. Permissions for the team's work items are assigned by assigning permissions to the area. There are other team settings that configure the team's agile planning tools.

Permission Description
Create child nodes 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.
Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.
Delete this node 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.
Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.
Edit this node Can set permissions for this node and rename area nodes.
Consider adding this permission to any manually added users or groups that may need to delete, add, or rename area nodes.
Edit work items in this node Can edit work items in this area node.
Consider adding this permission to any manually added users or groups that may need to edit work items under the area node.
Manage test plans Can modify test plan properties such as build and test settings.
Consider adding Manage test suites permissions to any manually added users or groups that may need to manage test plans or test suites under this area node.
Manage test suites 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).
Consider adding Manage test suites permissions to any manually added users or groups that may need to manage test plans or test suites under this area node.
View permissions for this node Can view the security settings for this node.
View work items in this node Can view, but not change, work items in this area node.
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 Path (object-level)

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

Multiple teams may contribute to a team project. When that's the case, you can set up teams that are associated with an area. Permissions for the team's work items are assigned by assigning permissions to the area. There are other team settings that configure the team's agile planning tools. To learn more, see Set permissions to restrict access to work items.

You manage the security of each iteration path from the web portal or using the TFSSecurity command-line tool.

Members of the Project Administrators group are automatically granted these permissions for each iteration defined for a team project. Consider granting team administrators, scrum masters, or team leads permissions to create, edit, or delete iteration nodes.

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

Permission Description
Create child nodes 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.
Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.
Delete this node 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.
Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.
Edit this node Can set permissions for this node and rename iteration nodes.
Consider adding this permission to any manually added users or groups that might need to delete, add, or rename iteration nodes.
View permissions for this node Can view the security settings for this node.
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.

##   Work item query and folder (object-level)

You manage query and query folder permissions through the web portal. Project Administors are granted all of these permissions. Contributors are granted Read permissions only. Consider granting the Contribute permissions to users or groups that require the ability to create and share work item queries for the team project.

Consider granting the Contribute permissions to users or groups that require the abilityto create and share work item queries for the team project. To learn more, see Set permissions on queries.

To create query charts you need Basic access.

Permission Description
Contribute Can view and modify this query or query folder.
Delete Can delete a query or query folder and its contents.
Manage permissions Can manage the permissions for this query or query folder.
Read Can view and use the query or the queries in a folder, but cannot modify the query or query folder contents.

::: moniker range="vsts || >= tfs-2017"

##   Delivery Plans (object-level)

You manage plan permissions through the web portal. You manage permissions for each plan through it's Security dialog. Project Administors are granted all permissions to create, edit, and manage plans. Valid users are granted View (read-only) permissions.

Note

For VSTS and TFS 2017.2 and later versions, you can access plans by installing the Delivery Plans Marketplace extension.

Permission Description
Delete Can delete the selected plan.
Edit Can edit the configuration and settings defined for the selected plan.
Manage Can manage the permissions for the selected plan.
View Can view the lists of plans, open and interact with a plan, but cannot modify the plan configuration or settings.

::: moniker-end

::: moniker range="vsts"

##   Inherited process (object-level)
You can manage the permissions for each inherited process that you create through the web portal. You manage permissions for each process through it's Security dialog. Project Collection Administors are granted all permissions to create, edit, and manage plans. Valid users are granted View (read-only) permissions.

Permission Description
Administer process permissions Can set or change the permissions for an inherited process.
Create process Can create an inherited process from a system process, or copy an inherited process.
Delete process Can delete the inherited process.
Edit process Can modify the inherited process.
::: moniker-end

##   Work item tags

You manage tagging permissions mostly from the TFSSecurity command-line tool. Contributors can add tags to work items and use them to quickly filter a backlog, board, or query results view.

Permission Description
Create tag definition 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.

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 team 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 team project as part of the command syntax. Otherwise, your change will apply to the entire collection. Keep this in mind when changing or setting these permissions.

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

This permissions does not appear in the UI. It can only be set by using the [TFSSecurity](/tfs/server/ref/command-line/tfssecurity-cmd) command.

There is also no UI to explicitly delete a tag. Instead, when a tag has not been in use for 3 days, TFS automatically deletes it.

Enumerate tag definition 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.

This permissions does not appear in the UI. It can only be set by using the [TFSSecurity](/tfs/server/ref/command-line/tfssecurity-cmd) command.

The **View project-level information** implicitly allows users to view existing tags.

Update tag definition Can rename a tag by using the REST API.
This permissions does not appear in the UI. It can only be set by using the [TFSSecurity](/tfs/server/ref/command-line/tfssecurity-cmd) command.

::: moniker range="tfs-2015"

##   Release (object-level)

If you are working with the Release Management client and server supported for TFS 2015, see Automate deployments with Release Management.

::: moniker-end

::: moniker range="vsts || >= tfs-2017"

##   Release (object-level)

You manage permissions for each release defined in the web portal. Project Administrators and Release Administrators are granted all release management permissions. These permissions can be granted or denied in a hierarchical model at the team project level, for a specific release definition, or for a specific environment in a release definition. Within this hierarchy, permissions can be inherited from the parent or overridden.

In addition, you can assign approvers to specific steps within a release definition to ensure that the applications being deployed meet quality standards.

The following permissions are defined in Release Management. The scope column explains whether the permission can be set at the team project, release definition, or environment level.

Permission Description Scopes
Administer release permissions Can change any of the other permissions listed here. Project, Release definition, Environment
Create releases Can create new releases. Project, Release definition
Delete release definition Can delete release definition(s). Project, Release definition
Delete release environment Can delete environment(s) in release definition(s). Project, Release definition, Environment
Delete releases Can delete releases for a definition. Project, Release definition
Edit release definition Can save any changes to a release definition, including configuration variables, triggers, artifacts, and retention policy as well as configuration within an environment of the release definition. To make changes to a specific environment in a release definition, the user also needs Edit release environment permission. Project, Release definition
Edit release environment Can edit environment(s) in release definition(s). To save the changes to the release definition, the user also needs Edit release definition permission. This permission also controls whether a user can edit the configuration inside the environment of a specific release instance. The user also needs Manage releases permission to save the modified release. Project, Release definition, Environment
Manage deployments Can initiate a direct deployment of a release to an environment. This permission is only for direct deployments that are manually initiated by selecting the Deploy action in a release. If the condition on an environment is set to any type of automatic deployment, the system automatically initiates deployment without checking the permission of the user that created the release. Project, Release definition, Environment
Manage release approvers Can add or edit approvers for environment(s) in release definition(s). This permissions also controls whether a user can edit the approvers inside the environment of a specific release instance. Project, Release definition, Environment
Manage releases Can edit the configuration in releases. To edit the configuration of a specific environment in a release instance, the user also needs Edit release environment permission. Project, Release definition
View release definition Can view release definition(s). Project, Release definition
View releases Can view releases belonging to release definition(s). Project, Release definition

Default values for all of these permissions are set for team project collections and team project groups. For example, Project Collection Administrators, Project Administrators, and Release Administrators are given all of the above permissions by default. Contributors are given all permissions except Administer release permissions. Readers, by default, are denied all permissions except View release definition and View releases.

::: moniker-end

##   Task group (Build and Release) permissions

You manage permissions for task groups from the Build and Release hub of the web portal. Project, Build, and Release Administrators are granted all permissions. Task group permissions follow a hierarchical model. Defaults for all the permissions can be set at the team project level and can be overridden on an individual task group definition.

You use task groups to encapsulate a sequence of tasks already defined in a build or a release definition into a single reusable task. You define and manage task groups in the Task groups tab of the Build and Release hub.

Permission Description
Administer task group permissions Can add and remove users or groups to task group security.
Delete task group Can delete a task group.
Edit task group Can create, modify, or delete a task group.

::: moniker range=">= tfs-2013 <= tfs-2015"

##   Lab Management

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 team project level and collection-level Readers groups have only View lab resources (Read) permissions.

Note

Lab Management is deprecated for TFS 2017. We recommend that you use Build and Release Management instead of Lab Management for automated testing.

<tr>
	<td>Delete Environment and Virtual Machines</td>
	<td>Can delete environments and templates. The permission is checked for the object that is being deleted.
	</td>
</tr>

<tr>
	<td>Delete Environment and Virtual Machines</td>
	<td>Can delete environments and templates. The permission is checked for the object that is being deleted.
	</td>
</tr>

<tr>
	<td>Delete Lab Locations</td>
	<td>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.
	</td>
</tr>

<tr>
	<td>Edit Environment and Virtual Machines</td>
	<td>Can edit environments and templates. The permission is checked for the object that is being edited.
	</td>
</tr>
<tr>
	<td>Environment Operations</td>
	<td>Can start, stop, pause, and manage snapshots, in addition to performing other operations on an environment.
	</td>
</tr>
<tr>
	<td>Import Virtual Machine</td>
	<td>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. 
	</td>
</tr>

<tr>
	<td>Manage Child Permissions</td>
	<td>
		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. 
	</td>
</tr>

<tr>
	<td>Manage Lab Locations</td>
	<td>
		 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 team project level locations (project host group and project library share).
	</td>
</tr>

<tr>
	<td>Manage Permissions</td>
	<td>Can modify the permissions for a Lab Management object. This permission is checked for the object whose permissions are being modified.
	</td>
</tr>

<tr>
	<td>Manage Snapshots</td>
	<td>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.
	</td>
</tr>

<tr>
	<td>Pause Environment</td>
	<td>Can pause an environment.</td>
</tr>
<tr>
	<td>Start</td>
	<td>Can start an environment.</td>
</tr>
<tr>
	<td>Stop</td>
	<td>Can stop an environment.</td>
</tr>
<tr>
	<td>View Lab Resources</td>
	<td>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.	
<tr>
	<td>Write Environment and Virtual Machines</td>
	<td>Can create environments for a project host group. Users who have this permission for a project library share can store environments and templates.
	</td>
</tr>
Permission Description

::: moniker-end

##   Notifications or alerts

There are no UI permissions associated with managing email notifications or alerts. Instead, they can be managed using the TFSSecurity command line tool.

  • By default, members of the team project level Contributors group can subscribe to alerts for themselves.
  • Members of the Project Collection Administrators group, or users who have the Edit collection-level information can set alerts in that collection for others or for a team.
  • Members of the Project Administrators group, or users who have the Edit project-level information can set alerts in that team project for others or for a team.

You can manage alert permissions using TFSSecurity.

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.
GENERIC_READ EventSubscription Can view subscription events defined for a team project.
GENERIC_WRITE EventSubscription Can create alerts for other users or for a team.
UNSUBSCRIBE EventSubscription Can unsubscribe from an event subscription.

##Related notes