不幸的是,Team Build 没有像版本控制这样的成熟客户端对象模型。它在 2008 年要好得多,但它仍然缺乏自己的安全 API。因此,您必须将级别降低到服务器范围内提供的更基本的 Web 服务接口:
这是 Powershell 中的快速演示:
# add me to the Build Services security group
$tfs = Get-TfsServer njtfs -all
$user = $tfs.gss.ReadIdentityFromSource($tfs.GSS_SearchFactor::AccountName, "rberg")
$uri = $tfs.css.GetProjectFromName("Test-ConchangoV2").uri
$role = $tfs.gss.ListApplicationGroups($uri) | ? { $_.displayname -match "Build" }
$tfs.gss.AddMemberToApplicationGroup($role.Sid, $user.Sid)
# explicitly give me the Administer Builders permission
$ace = new-object $tfs.GSS_AccessControlEntry ADMINISTER_BUILD, $user.Sid, $false
$objectId = [Microsoft.TeamFoundation.PermissionNamespaces]::Project + $Uri
$tfs.AUTH.AddAccessControlEntry($objectId, $ace)
# print build-related ACLs
$tfs.AUTH.ReadAccessControlList($objectId) |
? { $_.actionId -like "*build" } |
ft -auto ActionId, Deny, @{
Label = "Name";
Expression = { $tfs.gss.ReadIdentity($tfs.GSS_SearchFactor::Sid, $_.Sid, $tfs.GSS_QueryMembership::none).DisplayName }
}
不幸的是,使用这种低级 API 并没有一站式购买“有效权限”。Auth 服务可以通过多个组成员身份解析应用于用户的各种 ACE,以及有限形式的父->子继承,但我认为它不知道版本控制层次结构——只知道“通用结构” "(又名团队项目 -> 领域和迭代)层次结构。幸运的是,构建权限只有 1 级深度(始终存储在团队项目根目录下),因此在您的情况下这应该不是问题。