残念ながら、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レベルの深さしかないため(常にチームプロジェクトルートに保存されます)、これが問題になることはありません。