Team Foundation Server Permissions
Permissions determine the authorization for user actions such as workspace administration and project creation. When you create a project in Team Foundation Server, four default groups are created for that project regardless of your choice of process template. By default, each of these groups has a set of permissions defined for them that govern what members of those groups are authorized to do.
Project Administrator
Contributor
Reader
Build Services
To manage default groups and to create custom groups, administrators must understand the meaning of the permissions and the security implications for explicitly setting permissions.
Note
This topic does not discuss permissions for Windows SharePoint Services or SQL Reporting Services. This topic only discusses permissions that you set in Team Foundation Server.
Permission Settings
There are two explicit authorization settings for permissions in Team Foundation Server: Deny and Allow. There is also an implicit authorization available which neither sets the permission to Allow nor sets the permission to Deny. This authorization is an implicit Deny setting that is referred to as Unset.
Deny
Deny denies authorization for the user or group to perform the actions stated in the permission description. Deny is the most powerful permission setting in Team Foundation Server. If a user belongs to a Team Foundation Server group that has a specific permission set to Deny, that user cannot perform that function, even if he or she belongs to another group that has that permission set to Allow. The only exception to this rule occurs when the user is a member of either the Project Administrators group for a project or the Team Foundation Administrators group. If a user is a member of the Project Administrators group for a project, the privileges of that group override an explicit Deny for that user in a project. Similarly, if a user is a member of the Team Foundation Administrators group, the privileges of that group override an explicit Deny for that user in Team Foundation Server.
Allow
Allow grants authorization for the user or group to perform the actions stated in the permission description. Allow is the second-most powerful permission setting in Team Foundation Server. It is the one that is set most frequently. If you do not explicitly set a permission to Allow, a user or group cannot perform that action in Team Foundation Server.
Unset
By default, most permissions in Team Foundation Server are not set to either Deny or Allow. The permissions are left unset, which implicitly denies both users and groups authorization to perform the actions specified in the permission description. However, 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.
Inheritance
When permission is unset for a user or group, the user or group can be affected by the explicit setting for the permission for groups to which they belong because permissions in Team Foundation Server are inherited. For example, if a user belongs to two custom groups in a project, and one of those groups has a permission that is explicitly set to Deny and the other group has the same permission unset, the user will not have permission to perform the actions controlled by that permission (the user inherits permissions from both groups, and the Deny takes precedence over the unset permission).
Note
Permissions that are set outside Team Foundation Server, such as Windows SharePoint Services, are not inherited in Team Foundation Server. They are not discussed in this topic.
Certain authorization settings take precedence over other authorization settings. In Team Foundation Server, the Deny permission takes precedence over all other permission settings, including Allow and Unset. For example, a user might belong to two groups in a project. For one group, the 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. In other words, the general rule for precedence in inheritance is Deny, Allow, Unset.
The only exception to this rule occurs when the user is a member of either the Project Administrators group for a project or the Team Foundation Administrators group. If a user is a member of the Project Administrators group for a project, the permissions of that group override an explicit Deny or an implicit Unset for that user in a project. Similarly, if a user is a member of the Team Foundation Administrators group, the permissions of that group override an explicit Deny or an implicit Unset for that user in Team Foundation Server.
Permissions Set Through the Team Foundation Server User Interface and Through the Command Line
Many of the permissions you might want to set for Team Foundation Server are controlled through the Team Foundation Server user interface. You can set these permissions on a server basis (server-level permissions) or on a project basis (project-level permissions). You can also set area-level permissions for viewing and interacting with work items on a project basis. For more information about which permissions are set for what users by default, and for what permissions to set for MSF for Agile Software Development or MSF CMMI Process Improvement groups, see Team Foundation Server Default Groups, Permissions, and Roles. For more information about how to set permissions for users and groups, see Managing Users and Groups and Managing Permissions. For more information about managing work items, see Working with Team Foundation Work Items.
Server-Level Permissions
Server-level permissions are not specific to a single project. Instead, they are set on a server-wide basis. You can set these permissions only for three categories of users:
Server-level users and groups, such as Team Foundation Administrators
Project-level groups that have been added to the server-level on your Team Foundation server
Custom groups you create and add to the server level
You can set these permissions in Team Foundation Server by right-clicking the server in Team Explorer, and then clicking Security. You can set these permissions by using the TFSSecurity command-line utility, except for those command-line utilities with a tf: designation. For those with the tf: designation, use the Permission command of the tf command-line utility for source control to set the permissions. For more information, see TFSSecurity Command-Line Utility Commands and Permission Command.
Permission Name |
Name at command line |
Description |
---|---|---|
Administer shelved changes |
tf: AdminShelvesets |
Users who have this permission can delete shelvesets created by other users. |
Administer warehouse |
ADMINISTER_WAREHOUSE |
Users who have this permission can change warehouse settings by using the ChangeSetting Web method of the WarehouseController.asmx Web service. For example, you could allow users to set the update interval for calculating the OLAP cubes. |
Administer workspaces |
tf: AdminWorkspaces |
Users who have this permission can create workspaces for other users and delete workspaces created by other users. |
Create a workspace |
tf: CreateWorkspace |
Users who have this permission can create a source control workspace. |
Create new projects |
CREATE_PROJECTS |
Users who have this permission can create new projects in Team Foundation Server. In order to successfully create new projects, these users must be members of the correct groups in SharePoint Products and Technologies and SQL Server. These groups vary depending on the version of the product being used. For more information, see How to: Set Team Foundation Server Administrator Permissions. |
Edit server-level information |
GENERIC_WRITE tf: AdminConfiguration tf: AdminConnections |
Users who have this permission can edit server-level permissions for users and groups on Team Foundation Server. They can add or remove server-level Team Foundation Server application groups from Team Foundation Server. When set through the menus, the Edit server-level information permission also implicitly allows the user to modify source control permissions. To grant all the above permissions from the command line, you must use the tf.exe Permission command to grant the AdminConfiguration and AdminConnections permissions as well as GENERIC_WRITE. ![]()
Default server groups such as Team Foundation Administrators cannot be removed.
|
Alter trace settings |
DIAGNOSTIC_TRACE |
Users who have this permission can change the trace settings for gathering more detailed diagnostic information about Team Foundation Server Web services. For more information about tracing, see Trace Settings for Team Foundation Server. |
Trigger Events |
TRIGGER_EVENT |
Users who have this permission can trigger project alert events within Team Foundation Server. This permission should only be assigned to service accounts. |
Manage process template |
MANAGE_TEMPLATE |
Users who have this permission can download, create, edit, and upload process templates to Team Foundation Server. |
View server-level information |
GENERIC_READ |
Users who have this permission can view server-level group membership and the permissions of those users. |
View system synchronization information |
SYNCHRONIZE_READ |
Users who have this permission can trigger synchronization events. This permission should only be assigned to service accounts. |
Project-Level Permissions
Project-level permissions are specific to a single project's users and groups. You can set these permissions in Team Foundation Server by right-clicking the project in Team Explorer, clicking Team Project Settings, and then clicking Security. You can also set these permissions by using the TFSSecurity command-line utility.
Permission Name |
Name at command line |
Description |
---|---|---|
Delete this project |
DELETE |
Users who have this permission can delete the project for which they have this permission from Team Foundation Server. |
Edit project-level information |
GENERIC_WRITE |
Users who have this permission can edit project-level permissions for users and groups on Team Foundation Server. |
Publish test results |
PUBLISH_TEST_RESULTS |
Users who have this permission can add and remove test results on the team project portal and add or remove test runs. |
View project-level information |
GENERIC_READ |
Users who have this permission can view project-level group membership and the permissions of those project users. |
Build-Level Permissions
Build-level permissions are specific to a single project's users and groups. You can set these permissions by right-clicking the project in Team Explorer, clicking Team Project Settings, and then clicking Security. Additionally, you can set these permissions by using the TFSSecurity command-line utility.
Permission Name |
Name at command line |
Description |
---|---|---|
Administer a build |
ADMINISTER_BUILD |
Users who have this permission can delete completed builds and stop current builds in progress. |
Edit build quality |
EDIT_BUILD_STATUS |
Users who have this permission can add information about the quality of the build through the user interface for Team Foundation Build. This information is stored in the database store for Team Foundation Build. |
Start a build |
START_BUILD |
Users who have this permission can start a build through the interface for Team Foundation Build or from the command line. This permission is also required to configure a build so that it is retained indefinitely. |
Write to build operational store |
UPDATE_BUILD |
This permission must be granted to the account under which the build service runs so that the database store for Team Foundation Build can be updated. This permission should be assigned only to service accounts and not to individual users. |
Work Item Tracking Area-Level Permissions
Area-level permissions are specific to a single project's users and groups. You can set these permissions by right-clicking the project in Team Explorer, clicking Areas and Iterations, and on the Area tab, clicking Security. Additionally, you can set these permissions by using the TFSSecurity command-line utility.
Note
Some work item tracking operations require multiple permissions. For example, you need multiple permissions to delete a node.
Permission Name |
Name at Command Line |
Description |
---|---|---|
Create and order child nodes |
CREATE_CHILDREN |
Users who have this permission can create new 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 |
DELETE |
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. Any child nodes under the deleted parent node are also deleted. |
Edit this node |
GENERIC_WRITE |
Users who have this permission can rename area nodes. |
Edit work items in this node |
WORK_ITEM_WRITE |
Users who have this permission can edit work items in this area node. |
View this node |
GENERIC_READ |
Users who have this permission have access to view the security settings for this node. |
View work items in this node |
WORK_ITEM_READ |
Users who have this permission can view, but not edit or change, work items in this area node. |
Work Item Tracking Iteration-Level Permissions
Iteration-level permissions are specific to a single project's users and groups. You can set these permissions by right-clicking the project in Team Explorer, clicking Areas and Iterations, and on the Iterations tab, clicking Security. Additionally, you can set these permissions by using the TFSSecurity command-line utility.
Note
Some work item tracking operations require multiple permissions. For example, you need multiple permissions to delete a node.
Permission Name |
Name at Command Line |
Description |
---|---|---|
Create and order child nodes |
CREATE_CHILDREN |
Users who have this permission can create new iteration nodes. Users who have both this permission and the Edit this node permission can move or re-order any child iteration nodes. |
Delete this node |
DELETE |
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. Any child nodes under the deleted parent node are also deleted. |
Edit this node |
GENERIC_WRITE |
Users who have this permission can rename iteration nodes. |
View this node |
GENERIC_READ |
Users who have this permission have access to view the security settings for this node. |
Source Control Permissions
Source control permissions are specific to source code files and folders. You can set these permissions by right-clicking the folder or file in Source Control Explorer, clicking Properties, and on the Security tab, selecting the user or group for which you want to change permissions, and then editing the permissions listed in Permissions. You can set these permissions by using the tf command-line utility for source control.
Permission Name |
Name at Command Line |
Description |
---|---|---|
Read |
tf: Read |
Users who have this permission 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 permissions to open the files. |
Check out |
tf: PendChange |
Users who have this permission can check out and make a pending change to items in a folder. Examples of pending changes include adding, renaming, deleting, undeleting, branching, and merging a file. |
Check in |
tf: Checkin |
Users who have this permission can check in items and revise any committed changeset comments. Pending changes are committed at check-in. |
Label |
tf: Label |
Users who have this permission can label items. |
Lock |
tf: Lock |
Users who have this permission can lock and unlock folders or files. |
Revise other user's changes |
tf: ReviseOther |
Users who have this permission can edit the comments on checked in files, even if another user checked in the file. |
Unlock other user's changes |
tf: UnlockOther |
Users who have this permission can unlock files locked by other users. |
Undo other user's changes |
tf: UndoOther |
Users who have this permission can undo a pending change made by another user. |
Administer labels |
tf: LabelOther |
Users who have this permission can edit or delete labels created by another user. |
Manipulate security settings |
tf: AdminProjRights |
Users who have this permission can set permissions on these files and folders. |
Check in other user's changes |
tf: CheckinOther |
Users who have this permission can check in changes that were made by other users. Pending changes will be committed at check-in. |
See Also
Tasks
How to: Set Team Foundation Server Administrator Permissions
How to: Set Team Foundation Server Project Lead Permissions
How to: Set Team Foundation Server Contributor Permissions
How to: Set Team Foundation Server Reader Permissions
Concepts
Team Foundation Server Default Groups, Permissions, and Roles
Working with Team Foundation Work Items
Other Resources
TFSSecurity Command-Line Utility Commands
Team Foundation Version Control Command-Line Reference
Change History
Date |
History |
Reason |
---|---|---|
June 2010 |
Clarified precedence in inheritance between Deny, Allow, and Unset. |
Customer feedback. |