共用方式為


Set work tracking permissions

TFS 2018

To manage work tracking effectively, you can grant or restrict access to different features. Do so by assigning specific permissions to users or groups for a particular object, project, or collection. You also can define custom rules for processes or projects that apply to specific users or groups, thereby controlling their actions accordingly. For most features, we recommend that you add users to the project's Contributors group, which grants comprehensive access and ensures a seamless and efficient work tracking experience.

Prerequisites

Understand roles and permission levels for work tracking

The following table summarizes the different permissions you can set at the object, project, or collection level. The team administrator role provides access to add and modify team resources. Also, see Default permissions for Boards, Backlogs, Sprints, Delivery Plans, Test Management, and Queries, further in this article.


Role or permission level

Functional areas set


Team administrator role
Add a team administrator


Object-level permissions


Project-level permissions


Project collection-level permissions
Includes all permissions you can set at the collection-level.


For more information, see Add groups.

Default permissions for Boards, backlogs, and sprints

Boards default permissions

Task

Readers

Contributors

Team admins
Project admins

View boards and open work items

✔️

✔️

✔️

Add work items to a board; update status, reorder, or reparent child items through drag-and-drop; update a field on a card

✔️

✔️

Add child items to a checklist

✔️

✔️

Assign to a sprint (from card field)

✔️

✔️

Configure board settings

✔️

Backlogs default permissions

Task

Readers

Contributors

Team admins
Project admins

View backlogs and open work items

✔️

✔️

✔️

Add work items to a backlog

✔️

✔️

Use bulk edit features

✔️

✔️

Add child items to a backlog item; prioritize or reorder a backlog; parent items using the Mapping pane; Assign items to a sprint using drag-and-drop

✔️

✔️

Configure team settings, backlog levels, show bugs, work days off

✔️

Sprints default permissions

Task

Readers

Contributors

Team admins Project admins

Add work items to a sprint backlog or taskboard

✔️

✔️

Prioritize/reorder a sprint backlog or taskboard; add child items to a backlog item; reassign items to a sprint using the Planning pane

✔️

✔️

View team capacity and work details

✔️

✔️

Set team capacity

✔️

Use bulk edit features

✔️

✔️

Define team sprints

✔️

Create child nodes, modify work items under an area or iteration path

Area path permissions let you grant or restrict access to edit or modify work items, test cases, or test plans assigned to those areas. You can restrict access to users or groups. You can also set permissions for who can add or modify areas or iterations for the project.

  1. From the web portal for the project, select Settings.

    Screenshot showing opening Web portal, Open Admin context, project level for TFS 2018.

    If you're working from a team context, then hover over the gear icon and select Project settings.

    Screenshot showing Open Project Settings for TFS 2018.

  2. Select Work > Areas.

  3. Select the ... context menu for the node you want to manage and choose Security.

    Screenshot showing context menu, select Security for TFS 2018.

Default permissions for work items

Task or permission

Readers

Contributors

Project admins


View work items in this node (Area Path permission)

✔️

✔️

✔️

Edit work items in this node (Area Path permission)

✔️

✔️

Create tag definition

✔️

✔️

Email work items

✔️

✔️

✔️

Apply a work item template

✔️

✔️

Delete and restore work items (Project-level permission) (able to restore from the Recycle bin)

✔️

✔️

Permanently delete work items (Project-level permission)

✔️

Provide feedback (through the Microsoft Feedback client)

✔️

✔️

✔️

✔️

Note

Work items are subject to rules applied to them. Conditional rules based on user or group membership are cached for your web browser. If you find yourself restricted to update a work item, you may have encountered one of these rules. If you believe you've encountered an issue that doesn't apply to you, see Work item form IndexDB caching issues. For more information, see Rules and rule evaluation.

Use custom rules

Custom rules don't control permissions, but they affect whether a user can modify a work item or set the value of a work item field. Azure Boards supports the following work tracking customizations that support business workflows.

Customization Examples
Apply rules upon work item creation, state change, and specified state. - Make a field read-only
- Make a field required
Apply rules when a field value is empty, set to a specific value, or change or not changed to a value. - Clear the value of a field if it's empty or meets certain criteria
- Set a predefined value for the field if it's empty or meets specific conditions
- Copy the value of one field to another field
- Hide a field based on certain conditions or values
Apply rules that dictate what state a work item can get moved to from a given state. - Reassign a work item based on state changes
- Specify that a work item can only transition from "State A" to "State B"
- Manage the state transitions of parent work items based on the state changes of their child work items
Apply rules based on user or group membership of the user modifying a work item. Specify rules that restrict a group from creating a work item, transitioning a work item to a closed or completed state, or changing the value of a field

There are some restrictions for applying custom rules to system fields. For example, you can't specify rules that set or clear the value for Area Path or Iteration Path as they're system fields. For more information, see Rules and rule evaluation and Sample rule scenarios.

Set permissions on queries or query folders

You can specify who can add or edit query folders or queries at the object-level. To manage permissions for a query or query folder, you must be the creator of the query or folder, a member of the Project Administrators or Project Collection Administrators group or granted explicit access through the object's Security dialog.

Query folder permissions dialog

Screenshot of Permissions dialog for a query folder, Azure DevOps Server 2022 and earlier versions.

For more information, see Create managed queries to list, update, or chart work items.

Default permissions for queries

Tip

By default, Contributors can't create and save shared queries. We recommend that Project Administrators create a query folder for each team and give the team administrators or the team group query permissions to manage their folder. You need Delete permissions to rename or move a shared query or folder, and Contribute permissions for the folder where you move the query to. To learn more, see Set permissions on queries and query folders.

Task

Readers

Contributors

Project admins


Create and save managed My queries, query charts

✔️

✔️

Create, delete, and save Shared queries, charts, folders

✔️

Adhoc searches are powered by a semantic search engine.

Set permissions for work item tags

By default, all users of the Contributors group can create and add tags to work items. To set permissions for a group or user to restrict this ability, you can set the Create tag definition to Deny at the project-level. To learn how, see Change the permission level for a project-level group.

Manage permissions for Delivery Plans

Delivery Plans are an object within a project. You can manage permissions for each plan like the way you manage permissions for shared queries or query folders. The creator of a Delivery Plan and all members of the Project Collection Administrators and Project Administrators groups have permissions to edit, manage, and delete plans.

Users granted Stakeholder access for private projects have no access to delivery plans, while users granted Stakeholder access for public projects has the same access as regular Contributors granted Basic access. For a comparison chart of Stakeholder versus basic access, see the Feature Matrix.

To edit the permissions for a Delivery Plan, you must be the creator of the plan, a member of the Project Administrators or Project Collection Administrators group, or granted explicit permission through the plan's Security dialog.

  1. Select Work > Plans. For more information, see Review team delivery plans.

  2. To grant permissions to a group or user to manage or edit a specific plan, choose the actions icon to open the Security dialog for the plan.

    Screenshot showing the Security button for plan permissions, highlighted by a red box.

  3. Add a user, team group, or other security group who you want to grant permissions to or restrict access. (For details, see Change project-level permissions). By default, nonadministrators can't delete or edit a plan.

  4. With the user or group selected, set the permission you want them to have to Allow.

    Screenshot showing the permissions dialog for a delivery plan.

  5. Save when you're done.

Default permissions for Delivery Plans

Task

Readers

Contributors

Team admins
Project admins

Create, edit, or delete a delivery plan, Contributors can only edit or delete plans that they create

✔️

✔️

Manage permissions for a delivery plan, Contributors can only manage permissions for plans that they create

✔️

✔️

Manage test plans and test suites

In addition to the project-level permissions set in the previous section, team members need permissions to manage test artifacts that are set for an area path.

Open the Security page for area paths and choose the user or group you want to grant permissions.

Screenshot showing opened Area path permissions for project.

Set the permissions for Manage test plans and Manage test suites to Allow.

Screenshot showing access set to Allow for test plans and suites.

To have full access to the Test feature set, your access level must be set to Basic + Test Plans. Users with Basic access and with permissions to permanently delete work items and manage test artifacts can only delete orphaned test cases.

Default permissions for test management

Test plans, test suites, test cases and other test artifacts are specific work item types that support manual and exploratory testing. For more information, see Set test permissions at the project level.

Permission

Level

Readers

Contributors

Project Admins

View test runs

Project-level

✔️

✔️

✔️

Create test runs
Delete test runs

Project-level

✔️

✔️

Manage test configurations
Manage test environments

Project-level

✔️

✔️

Create tag definition
Delete and restore work items

Project-level

✔️

✔️

Permanently delete work items

Project-level

✔️

View work items in this node

Area Path

✔️

✔️

✔️

Edit work items in this node
Manage test plans
Manage test suites

Area Path

✔️

✔️

Area permissions for web-based test case management and test execution control access to the following actions.

The Manage test suites permission enables users to do the following tasks:

  • Create and modify test suites
  • Add or remove test cases to/from test suites
  • Change test configurations associated with test suites
  • Modify the suite hierarchy by moving a test suite

The Manage test plans permission enables users to do the following tasks:

  • Create and modify test plans
  • Add or remove test suites to or from test plans
  • Change test plan properties such as build and test settings

More access options for work items

For more information about options for customizing work item types to support restrictions, see Restrict access, Restrict modification of work items based on a user or group.

Grant team members additional permissions

For teams to work autonomously, you may want to provide them with permissions that they don't have by default. Suggested tasks include providing team administrators or team leads permissions to:

By default, team members inherit the permissions afforded to members of the project Contributors group. Members of this group can add and modify source code, create and delete test runs, and create and modify work items. They can collaborate on a Git project or collaborate with other team members and check in work to the team's code base (TFVC).

Screenshot of default permissions assigned to team contributors.

If your on-premises deployment includes reporting, add users to those resources. See Grant permissions to view or create SQL Server reports.