К сожалению, Team Build не имеет полноценной клиентской объектной модели, такой как Version Control. Это намного лучше в 2008 году, но у него все еще нет собственного API безопасности. Таким образом, вам нужно перейти на более низкий уровень к более базовым интерфейсам веб-сервисов, предлагаемым для всего сервера:
Вот краткая демонстрация в 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 нет единой возможности приобрести «эффективные разрешения». Служба аутентификации может разрешать различные ACE, которые применяются к пользователю через членство в нескольких группах, а также ограниченную форму наследования родительских и дочерних элементов, но я не думаю, что она знает об иерархии управления версиями - только «общая структура (иерархия командных проектов -> областей и итераций). К счастью, разрешения на сборку имеют глубину только 1 уровень (всегда хранится в корне Team Project), поэтому в вашем случае это не должно быть проблемой.