Team Foundation Server Permissions

vstsuetb

Authorization for user actions, such as workspace administration and project creation, are determined by permissions. 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 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 which 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.

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 and the one most frequently set, because without a permission explicitly set to Allow, a user or group cannot perform any actions 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 as 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 of which they are a member because permissions within Team Foundation Server are inheritable. If a permission is explicitly set for one group a user belongs to, and not set in another group that the user belongs to, the user inherits the allow or deny for that permission from the other group.

Note   Permissions that are set outside Team Foundation Server, such as Windows SharePoint Services, are not inherited within Team Foundation Server and not discussed in this topic.

Certain authorization settings take precedence over other authorization settings. Within Team Foundation Server, 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.

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.

Server-Level Permissions

Server-level permissions are not specific to a single project, but instead are set on a server-wide basis. You can only set these permissions for server-level users and groups, such as Team Foundation Administrators, for project-level groups that have been added to the server-level on your Team Foundation server, and for the 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 clicking Security. You can set these permissions by using the TFSSecurity command-line utility, except for those noted with a tf: designation. You can set those permissions by using the Permissions command of the tf command-line utility for source control.

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 have Administrator permissions in Windows SharePoint Server and SQL Reporting Services.

Edit server-level information

GENERIC_WRITE

Users who have this permission can edit server-level groups and permissions. They can create, delete, and rename server-level Team Foundation Server application groups, add or remove a Windows user or group for that application group. This permission also implicitly grants version control write access.

Note   Default server groups such as Team Foundation Administrators cannot be deleted.

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.

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.

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 and 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.

Delete this project

DELETE

Users who have this permission can delete projects from Team Foundation Server.

Edit build quality

EDIT_BUILD_STATUS

Users who have this permission can add information about the quality of the build through the Team Foundation Build user interface. This information is stored in the Team Foundation Build database store.

Edit project-level information

GENERIC_WRITE

Users who have this permission can edit project-level groups and permissions. They can also create, delete, and rename project-level groups in the project, add or remove Windows users and groups to the project, and add or remove Team Foundation Server users or groups from the project. They can also change project permissions for these users and groups and add or remove project-level work item tracking queries.

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.

Start a build

START_BUILD

Users who have this permission can start a build through the Team Foundation Build user interface or from the command line.

View project-level information

GENERIC_READ

Users who have this permission can view project-level group membership and the permissions of those project users.

Write to build operational store

UPDATE_BUILD

This permission must be granted to the account under which the Build Service is running, in order to update the Team Foundation Build database store. This permission should only be assigned 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.

Permission Name

Name at Command Line

Description

Create and order child nodes

CREATE_CHILDREN

Users who have this permission can create new area nodes and re-order any child area nodes.

Delete this node

DELETE

Users who have this permission can delete area nodes. 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.

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 Permissions, and on the Security tab, selecting the user or group for which you want to change permissions, and 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.

 

0 comments

Discussion is closed.

Feedback usabilla icon