如何配置旧项目DevOps Boards只读权限，保留Repos等功能读写权限

Hey there! Let’s walk through exactly how to set up these permissions for your team in the old Azure DevOps project. The goal here is to lock down Boards to read-only while keeping full access to Repos, Pipelines, and Test Plans—and using security groups will make this way easier than configuring permissions one person at a time.

First, let’s centralize your team into a security group to avoid repeating settings for every member:

• Go to your old project’s Project Settings (the gear icon at the bottom left of the sidebar).
• Under Security, select Groups. If you don’t have a dedicated team group, click New Group to create one and add all your team members. If you’re already using the default team group (like [Your Project Name] Team), that works too—just double-check everyone’s included.

Now let’s restrict Boards to view-only access. Do this directly in Boards settings for precision:

• From the project sidebar, navigate to Boards > Boards Settings, then select Permissions.
• Choose your team group from the list, then adjust these key permissions:
  • View work items in this node: Set to Allow (so members can still see all work items)
  • Edit work items in this node: Set to Deny (blocks any changes to existing work items)
  • Create work items in this node: Deny (prevents new items from being added)
  • Delete work items in this node: Deny (avoids accidental deletions)
• Optional: If you don’t want members creating or editing queries, set Manage queries to Deny—though some teams let members save their own read-only queries, so adjust this based on your needs.

Now let’s make sure your team retains full access to the other services:

For Repos #

• Go to Repos > Repos Settings and select Permissions.
• Find your team group, then set these permissions to Allow:
  • Contribute: Lets members push code, edit files, and make commits
  • Create branch: Allows spinning up new branches for work
  • Create tag: For version tagging
  • Manage branches: Enable this if your team needs to create/delete branches (adjust if you have strict branch policies)
• The Read permission should be inherited, but double-check to confirm it’s set to Allow.

For Pipelines #

• Head to Pipelines > Pipelines Settings and choose Permissions.
• Select your team group, then enable:
  • Edit build pipelines: Lets members create new pipelines or modify existing ones
  • Queue builds: Allows triggering pipeline runs
  • Manage builds: Lets members cancel runs, edit build history, etc.
• Optional: Set Administer build permissions to Allow if you want members to manage pipeline permissions for others—otherwise, leave it as Not Set.

For Test Plans #

• Go to Test Plans > Test Plans Settings and select Permissions.
• For your team group, set:
  • Contribute: Lets members create, edit test cases, suites, and plans
  • Manage test plans: Allows organizing and structuring test plans
• Confirm the Read permission is set to Allow (it should be inherited, but it’s safe to check).

Once all settings are in place, test to make sure everything works as intended:

• Use the Impersonate feature in Project Settings > Security > Users: Pick a team member, click Impersonate, then check:
  • Can they view work items in Boards but not edit or create them?
  • Can they push code to Repos, edit pipelines, and modify test plans without issues?

If your team group is part of the default Contributors group (which usually has full access to all services), don’t worry—your Deny settings for Boards will take precedence over the Contributors’ Allow permissions, so the read-only restriction will still apply.

内容的提问来源于stack exchange，提问作者BillQ