Merk
Tilgang til denne siden krever autorisasjon. Du kan prøve å logge på eller endre kataloger.
Tilgang til denne siden krever autorisasjon. Du kan prøve å endre kataloger.
Azure DevOps Services | Azure DevOps Server | Azure DevOps Server 2022
Use this article to grant or restrict access to Azure Boards tasks at the object, project, or collection level. Choose a permission scope to find the requirements and instructions for your task.
For routine work tracking access, add users to the project's Contributors group. To review the permissions assigned to built-in groups, see Default permissions and access levels for Azure Boards. To restrict fields or state transitions instead of access to features or objects, use a custom rule.
Prerequisites
| Category | Requirements |
|---|---|
| Permissions | Member of the Project Administrators group or explicit permission to manage the work tracking area as described in this article. |
| Category | Requirements |
|---|---|
| Permissions | Member of the Project Collection Administrators group or have explicit permissions to edit a collection process. |
Choose the permission scope
Use this table to find the scope, requirements, and instructions for your task.
| Task | Scope | Requirements | Instructions |
|---|---|---|---|
| Configure team settings and resources | Team administrator | Team administrator or member of Project Administrators | Add a team administrator |
| Manage work items or child nodes under an area or iteration path | Object | Applicable area or iteration path permissions set to Allow | Set area and iteration path permissions |
| Manage queries or query folders | Object | At least Basic access and the applicable query permissions | Set query and query-folder permissions |
| Create work item tags | Project | At least Basic access and Create tag definition set to Allow | Set work item tag permissions |
| Manage a Delivery Plan | Object | Plan creator, administrator, or applicable plan permissions | Set Delivery Plan permissions |
| Move or permanently delete work items | Project | Applicable project-level permission set to Allow | Set move and permanent-delete permissions |
| Manage test plans and test suites | Area path and access level | Eligible Test Plans access and applicable area path permissions | Set test plan and test suite permissions |
| Manage inherited processes | Collection or process | Member of Project Collection Administrators or applicable process permissions | Set inherited process permissions |
For a consolidated reference, see Default permissions quick reference. For testing-specific access and defaults, see Manual test access and permissions.
Set area and iteration path permissions
Area and iteration path permissions control who can view or edit work items and who can manage child nodes. Set these permissions for a user or security group on the applicable path.
Note
Permission to create or edit paths doesn't grant permission to assign paths to a team. To configure team paths, be a team administrator or a member of Project Administrators.
To set permissions for an area or iteration path:
Select Project settings > Project configuration > Areas or Iterations.
Open More actions for the node that you want to manage, and then select Security.
Select the user or group. To add an identity, enter its name in the search box.
Set the permissions required for the task to Allow or Deny. For example, use View work items in this node and Edit work items in this node to control access to work items, or Create child nodes to delegate path creation.
For information about explicit and inherited permission states, see About permissions, access, and security groups.
(Optional) Turn off Inheritance to stop inheriting permission changes from the parent node.
Close the dialog. Reopen Security, select the user or group, and confirm that the intended permission states appear.
To set permissions for an area or iteration path:
Select Project settings > Project configuration > Areas or Iterations.
Open More actions for the node that you want to manage, and then select Security.
Select the user or group. To add an identity, enter its name in the search box.
Set the permissions required for the task to Allow or Deny.
For information about explicit and inherited permission states, see About permissions, access, and security groups.
(Optional) Turn off Inheritance to stop inheriting permission changes from the parent node.
Close the dialog. Reopen Security, select the user or group, and confirm that the intended permission states appear.
Use a custom rule for field or state restrictions
Custom rules don't grant or deny access to features or objects. Use them to control work item creation, field behavior, or state transitions for specific users or groups.
Custom rules can't set or clear Area Path or Iteration Path. For supported conditions, actions, and restrictions, see Rules and rule evaluation and Sample custom rule scenarios.
Parent-state automation is a separate team backlog feature. For more information, see Automate work item state transitions.
Set query and query-folder permissions
To create or edit a shared query, you need at least Basic access and Contribute set to Allow for the shared query folder. To change permissions on a query or folder, you need Manage Permissions set to Allow for that folder.
Follow the steps in Set permissions on queries and query folders. After you save the change, reopen the folder's Security dialog and select the user or group to verify the permissions.
Set work item tag permissions
To create a tag, you need at least Basic access and the project-level Create tag definition permission set to Allow. The Contributors group has this permission by default. Denying this permission prevents users from creating tag definitions, but it doesn't prevent them from assigning existing tags to work items that they can edit.
- Open the project permission page as described in Change project-level permissions.
- Select the user or group.
- Set Create tag definition to Allow or Deny.
- Reselect the user or group and confirm that the intended permission state appears.
Set Delivery Plan permissions
Delivery Plans are secured objects within a project. Plan creators and members of Project Administrators or Project Collection Administrators can edit, delete, and manage permissions for a plan. Other users need explicit permissions through the plan's Security dialog. Users with Stakeholder access can view plans but can't add or edit them.
Open Boards > Delivery Plans.
Open
More actions for the plan, and then select Security.
Add or select the user or group whose access you want to change.
Set View, Edit, Delete, or Manage to Allow or Deny. Manage controls whether the user can change permissions for the plan.
Close the dialog. Reopen Security, select the user or group, and confirm that the intended permission states appear.
Set move and permanent-delete permissions
By default, members of Contributors and Project Administrators can change work item types and move deleted work items to the Recycle Bin. Other operations have additional requirements:
- To delete and restore work items, have at least Basic access and Delete and restore work items set to Allow.
- To move work items to another project, be a member of Project Administrators or have Move work items out of this project set to Allow. This permission isn't granted to Contributors by default, and the feature isn't available to users with Stakeholder access.
- To permanently delete work items, have Permanently delete work items set to Allow. This permission is granted to Project Administrators by default.
Open the project permission page as described in Change project-level permissions.
Select the user or group.
Set Move work items out of this project or Permanently delete work items to Allow or Deny.
Reselect the user or group and confirm that the intended permission state appears.
Note
In Azure DevOps Server, moving work items also requires the Inheritance process model and a disabled data warehouse. For complete requirements, see Move work items and change work item type.
For instructions to perform these operations, see Move work items and change work item type and Remove, delete, or restore work items.
Set test plan and test suite permissions
To use all Azure Test Plans features, have Basic + Test Plans access or an eligible Visual Studio Enterprise, Visual Studio Test Professional, or MSDN Platforms subscription. Test artifacts also require project-level and area path permissions. For complete requirements, see Manual test access and permissions.
Open the Security dialog for the applicable area path.
Select the user or group.
Set Manage test plans and Manage test suites to Allow.
Close the dialog. Reopen Security, select the user or group, and confirm that both permissions are set to Allow.
Users with Basic access can execute tests, but they can't create or manage test plans and suites. With the required permissions, they can permanently delete only orphaned test cases.
Deleted test plans and test suites remain recoverable for 14 days. For recovery steps and limitations, see Delete test artifacts.
Deleted test artifacts can't be restored in Azure DevOps Server. For details, see Delete test artifacts.
Set inherited process permissions
By default, only Project Collection Administrators can create, edit, and delete inherited processes. These administrators can delegate the Create process, Delete process, or Edit process permission at the collection level. For more information, see Change collection-level permissions.
To let a user or group customize a specific inherited process:
Note
Users added to the Project-Scoped Users group can't access process settings if the Limit user visibility and collaboration to specific projects preview feature is enabled for the organization. For more information including important security-related callouts, see Manage your organization, Limit user visibility.
Open Organization settings > Process.
Open More actions for the inherited process, and then select Security. For more information about opening process settings, see Customize a project using an inherited process.
Search for and select the user or group.
Set Edit process to Allow. Set other process permissions only when the identity needs those capabilities.
Close the dialog. Reopen Security, select the user or group, and confirm that Edit process is set to Allow.
Troubleshoot permission changes
- If a Security option or permission control isn't available, confirm that you have permission to manage security for that object or scope.
- If an action remains blocked after you set a permission to Allow, check the user's access level and trace their effective permissions. An explicit Deny inherited through another group can block the action.
- If a recently changed permission isn't reflected, refresh or reevaluate the user's permissions.
For diagnostic steps, see Troubleshoot access and permission issues.