Set permissions and access for work tracking
Azure DevOps Services | Azure DevOps Server 2019 | TFS 2018 | TFS 2017 | TFS 2015 | TFS 2013
You grant or restrict access to various work tracking features by granting users or groups specific permissions for an object, project, or collection. Or, when you assign a user as a team administrator, they have permissions to manage all assets for the specific team. Add users to the Contributors group to provide access to most features as listed in Permissions and access for work tracking.
For public projects, Stakeholder access gives users greater access to work tracking features and full access to Azure Pipelines. To learn more, see About access levels, Stakeholder access.
|Role or permission level||Functional areas set|
|Team administrator role||
|Project collection-level permissions||
Edit project-level or collection-level/instance-level information
The Edit project-level information and Edit instance-level information (also referred to as Edit collection-level information) provide permissions to several work tracking features as summarized below. To add users or set permissions at these levels, see Add administrators, set permissions at the project-level or project collection-level.
|Edit project-level information||Edit instance-level information|
Create child nodes, modify work items under an area 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.
Your web portal uses either the New navigation or Previous navigation user interface. Choose the New navigation tab if the New Navigation feature is enabled. You'll see a vertical sidebar along with other navigational features when New Navigation has been enabled for the signed-in user or the organization. Choose Previous navigation when you see a top-level, blue-bar—indicating that New navigation isn't enabled. For more information, see Web portal navigation.
Choose the New navigation tab for guidance. Azure DevOps Server 2019 supports the New Navigation user interface. For more information, see Web portal navigation.
Choose the Previous navigation tab for guidance. TFS 2018 and earlier versions only support the previous navigation user interface. For more information, see Web portal navigation.
Define and edit queries or query folders
You can specify who can add or edit query folders or queries at the object-level. See Set permissions on a shared query or query folder to restrict who can modify the query or queries within a folder.
To learn more about queries, see Create managed queries to list, update, or chart work items.
Manage or edit Delivery plans
Plans are an object within a project. You manage plan permissions for each plan similar to the way you manage permissions for shared queries or query folders. The creator of a Delivery Plan as well as all members of the Project Collection Administrators and Project Administrators groups have permissions to edit, manage, and delete plans.
To learn more about Delivery Plans, see Review team delivery plans.
Feature availability: Delivery plans are available for TFS 2017.2 and later versions, you can access plans by installing the Delivery Plans Marketplace extension.
Open Work>Plans. For details, see Review team delivery plans.
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.
Add a user or group who you want to grant permissions to or restrict access. By default, non-administrators can't delete or edit a plan that you create.
With the user or group selected, set the permission you want them to have to Allow.
For example, here we grant permission to Raisa to edit the plan.
Move or permanently delete work items
By default, Project Administrators and Contributors can change the work item type and delete work items by moving them to the Recycle bin. Only Project Administrators can permanently delete work items and test artifacts. Project admins can grant permissions to other team members as needed.
For example, as a project admin you can grant a user, team group, or other group you've created to have these permissions. Open the Security page for the project and choose the user or group you want to grant permissions. (To learn how to access project-level Security, see Set permissions at the project-level or project collection-level.)
In this example, we grant members assigned to the team administrator role, who belong to the Team Admin groups, permissions to move work items to another project and to permanently delete work items.
Delete test artifacts
In addition to the project-level permissions set in the previous section, team members need permissions to manage test artifacts which are set for an area path.
Open the Security page for area paths and choose the user or group you want to grant permissions.
Set the permissions for Manage test plans and Manage test suites to Allow.
To have full access to the Test feature set, your access level must be set to Advanced. Users with Basic access and with permissions to permanently delete work items and manage test artifacts can only delete orphaned test cases.
Customize an inherited process
By default, only Project Collection Administrators can create and edit processes. However, these admins can grant permissions to other team members by explicitly setting the Create process, Delete process, or Edit process permissions at the collection level for a specific user.
To customize a process, you need to grant Edit process permissions to a user account for the specific process.
Open the … context menu for the inherited process and choose Security. To open this page, see Customize a project using an inherited process.
Add the account name of the person you want to grant permissions to, set the permissions to Allow that you want them to have, and then choose Save changes.
Here we add Christie Church and allow her to edit the process.
Each process is a securable unit and has individual access control lists (ACLs) that govern creating, editing, and deleting inherited processes. At the collection level, project collection administrators can choose which processes can be inherited from and by whom. When you create a new inherited process, the process creator as well as project collection administrators have full control of the process and can also set individual ACLs for other users and groups to edit and delete the process.
Additional options for restricting access to work items
You can use one or more of the following options with the On-premises XML process models. To learn more about process models, see Customize work tracking experience.
You can restrict access to work tracking objects in one of two ways:
- By adding WITs to the Hidden Categories group, you can prevent the majority of project contributors from creating them. You can create a hyperlink to a template that opens the work item form and share that link with those team members who you do want to create them.
- Set a condition field rule, a condition-based field rule or a combination of the two that applies to a group. You can restrict changes from being made to a field by specifying a qualifying rule and making it apply for a specific group. Conditional rules can include CANNOTLOSEVALUE, EMPTY, FROZEN, NOTSAMEAS, READONLY, and REQUIRED elements.
For more information about how to customize WITs, see Modify or add a custom work item type (WIT).