Set object-level permissions
TFS 2017 | TFS 2015 | TFS 2013
As you manage security for your organization, you can set permissions at the organization/collection-level, project-level, and object-level. This article helps you go to the security dialogs for setting permissions at the object-level, as the user interface varies somewhat across Azure Devops. For more information, see Get started with permissions, access, and security groups.
The following items are considered objects:
- General: Dashboards, Analytic views, Wikis, and notifications
- Boards: Area Paths, Iteration Paths, Shared queries and query folders, and more
- Pipelines: Build and release pipelines, deployment groups, task groups, and more
- Repos: Git repositories and branches, TFVC folders or branches
- Artifacts: Artifacts and feeds
Work items, work item tags, Git repository tags, test plans, test suites, test cases, and other test artifacts aren't objects, but are subject to the security settings or permissions, typically set at the project level or for an area path.
To set most object-level permissions, you must be a member of the Project Administrators group, or granted explicit permission through the individual object security dialog. Any permissions granted to Project Administrators are also granted to members of the Project Collection Administrators group.
Note
TFVC only supports a single repository per project. You can set permissions for the repository or repo folders/branches, which inherit from the repo.
For more information, see Security concepts and Security tasks.
Open the permissions dialog for an object section
There are various ways to get to the Permissions dialog for an object. The simplest way is to start from the object, and then select More ... > Security.
Note
Some objects, such as repositories and Analytics views, require Basic access or higher levels. For more information, see Access levels.
Set permissions for Dashboards, Wikis, and Analytic views
You can set permissions at the project-level and organization/collection-level for some general items, such as creating, deleting, and renaming projects. The following table provides information about setting permissions at the object-level for Dashboards, Wiki, and Analytic views.
Object
Default group membership
How to access security
Inherited?
Contributor
Open Dashboards, select the area path, and then More ... > Security.
✔️ (project settings for team dashboard)
Set permissions for Boards objects
The following table provides information about setting permissions at the object-level for area and iteration paths, work items, and more.
Object
Default group membership
How to access security
Inherited?
Open Project settings > Project configuration > Areas > next to an area, More ... > Security.
✔️ (child node from parent node)
Open Project settings > Project configuration > Iterations > next to an iteration, More ... > Security.
✔️ (child node from parent node)
Contributor
Open Project settings > Project configuration > Areas > Area path > the work item.
no
Creator of the query or folder or Project Administrator
Open the work item query or query folder > More ... > Security.
no
Select More ... > Security.
✔️ (from Organization/Collection settings)
Note
Work item tags - permissions get set at the project level, Create tag definition. Work item tags don't qualify as an object, they're defined through work items.
Tips
For Team members by role, the following two roles are explained.
- Changed reviewers applies to any reviewer that's added or deleted, because of policies defined for the set of files. For example, a push to a pull request (PR) can introduce a change to File1.cs. If a policy says Person A needs to review changes to File1.cs, they're in the Changed reviewers role for that iteration of the PR.
- The Reset reviewers role is related to the “reset votes” policy. For example, the repo has configured the policy, “Reset votes on new pushes”. Person B, who was required on the PR, has already approved this PR. Because of the "reset votes policy", their vote gets reset. So, they're in the Reset reviewers role for that iteration.
Set permissions for Repos objects
The following table provides information about setting permissions at the object-level for repos, Git repos, Git branches, and TFVC repos.
| Object | Default group membership | How to access security | Inherited? |
|---|---|---|---|
| Repos | Project Administrator | Open Project settings, Repositories > highlight your repo > Security. | ✔️ |
| Git repository | Project Administrator | Open Project settings > Repositories and the Git repository. | ✔️ (from project settings for Git repository) |
| Git branch | Project Administrator | Open Repos > Branches > your branch > More ... > Branch security. | ✔️ |
| TFVC repository | Project Administrator | Open Project settings > Repositories and the TFVC repository. | ✔️ |
Tips
- Branches inherit a subset of permissions from assignments made at the repository level. For more information about branch permissions and policies, see Set branch permissions and Improve code quality with branch policies
- Create a shared query folder for each team and provide permissions to create and edit queries under that folder to all members of the team.
- If you add a user to the Contributors group, they can add and modify work items. You can restrict user and group permissions based on the area path. For more information, see Set permissions and access for work tracking, Modify work items under an area path.
Set permissions for Pipelines objects
The following table provides information about setting permissions at the object-level for build pipelines, release pipelines, deployment groups, and more.
| Object | Default group membership | How to access security | Inherited? |
|---|---|---|---|
| Pipelines | Project Administrator | Open Pipelines > Pipelines > All > your pipeline > More ... > Manage security. | ✔️ |
| Build pipelines | Project Administrator | Open your build pipeline > More ... > Manage security. | ✔️ |
| Build pipeline runs | Project Administrator | Open your build pipeline run > More ... > Manage security. | ✔️ |
| Release pipelines | Project Administrator | Open your release pipeline > More ... > Manage security. | ✔️ |
| Task groups (Classic) | Project Administrator | Open your task group > More ... > Manage security. | ✔️ |
| Deployment groups | Project Administrator | Open your deployment group > More ... > Manage security. | ✔️ |
| Deployment pools | Project Administrator | Open your deployment pool > More ... > Manage security. | ✔️ |
| Environments | Project Administrator | Open your environment > More ... > Manage security. | ✔️ (from Environments permission settings) |
| Variable groups | Project Administrator | Open your variable group > More ... > Manage security. | ✔️ (from Library permission settings) |
| Secure files | Project Administrator | Open your secure file > More ... > Manage security. | ✔️ (from Library permission settings) |
Set permissions for Test plans objects
- Test plans, test suites, test cases, and other test objects are managed similarly to work items. This is because they represent test-specific work item types, as discussed in Test objects and terms.
- You can manage test-level permissions through project-level settings or through Area Path object-level settings. For more information, see Set permissions and access for testing.
Set object permissions through the command line
You can use the TFSSecurity command line tool.
Some more granular permissions and permissions for select objects and features can only be managed through the command line. For example:
- Notifications using the
EventSubscriptionandEventSubscribernamespaces - Read or create dashboards using the
DashboardPriveligesnamespace - Use, manage, or view service endpoints through the
ServiceEndpointsnamespace - View delivery plans through the
Plansnamespace
For more information about namespaces, see Security namespace and permission reference.
Set permissions for object notifications
Notifications can be set at the user, team, project, and organization/collection level. While there isn't a user interface for setting notification permissions, some permissions can be set through command line tools and the EventSubscription namespace. For more information, see Security namespace and permission reference.
Here are some additional tips for managing notifications.
- If you don't want to receive a notification for an event that you started, you can turn on the option, Skip initiator. For more information, see Exclude yourself from notification emails for events that you start.
- We don't support organization-wide notifications. As an alternative, you can provide an email distribution list that goes to your entire organization. Also, you can generate a banner with the
az devops bannercommand that all users see when they sign in.
Related articles
- Change project-level permissions
- Change project collection-level permissions
- Download permissions report for a repository
- Manage permissions with command line tool
- Get started with permissions, access, and security groups
- Permissions lookup reference
- Manage teams and configure team tools
- Security and permission management tools