残念ながら、Team BuildにはVersion Controlのような本格的なクライアントオブジェクトモデルはありません。 2008年の方がはるかに優れていますが、独自のセキュリティAPIはまだありません。だから、サーバ全体で提供され、より基本的なWebサービスのインターフェイスにレベルをステップダウンする必要があります。
:ここ
# 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 }
}
残念ながら、この低いレベルl APIには、「有効なアクセス許可」についてのワンストップショッピングはありません。 Authサービスは、複数のグループメンバーシップと、限定された親子継承を介してユーザーに適用されるさまざまなACEを解決できますが、バージョン管理階層についてはわかりません。一般的な構造"(別名Team Projects - > areas &イテレーション)幸運なことに、ビルドパーミッションは1レベル深いです(常にTeam Projectルートに格納されています)ので、あなたの場合は問題にならないはずです。
TFSのどのバージョンですか? 05または08? – RobS
使用しているバージョンはTFS 2008です。 – dabuild