不幸的是,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 }
}
不幸的是,有了這個低水平l API沒有「有效權限」的一站式購物。 Auth服務可以通過多個組成員身份解析應用於用戶的各種ACE,以及父 - >子繼承的有限形式,但我不認爲它知道版本控制層次結構 - 只有「常見結構「(又名團隊項目 - >區域&迭代)層次結構。幸運的是,構建權限的深度只有1級(始終存儲在團隊項目根目錄中),因此這不應該成爲您的問題。
哪個版本的TFS? 05或08? – RobS 2009-07-21 01:04:10
正在使用的版本是TFS 2008. – dabuild 2009-07-21 03:34:35