Пользовательские разрешения в TFS API - Начало сборки, администрирование сборки

Question

Я ищу способ узнать, имеет ли пользователь разрешение «Начать сборку» для данного проекта.

На данный момент я знаю, что объект VersionControlServer может использоваться для возврата строкового массива эффективных разрешений пользователя в рамках проекта. Но когда я запускаю метод GetEffectivePermissions на VersionControlServer, разрешения «Начать сборку» и «Администрировать сборку» не включаются в массив, в котором перечислены права пользователя.

Я предполагаю (неправильно?), Что это потому, что я запрашиваю VersionControlServer, который не контролирует разрешения на сборку.

Как я могу найти эффективные «связанные с построением» разрешения пользователя через API TFS 2008?

Answer 1

К сожалению, Team Build не имеет полномасштабной клиентской объектной модели, такой как Version Control. В 2008 году намного лучше, но до сих пор не хватает собственного API безопасности. Таким образом, вы должны выйти на один уровень с более основных веб-сервиса интерфейсов, предлагаемых на сервере:

• IAuthorization
• ICommonStructure
• IGroupSecurity

Вот краткий демо в 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, которые применяются к пользователю через множественное членство в группе, а также ограниченную форму родительского> дочернего наследования, но я не думаю, что он знает об иерархии управления версиями - только «общая структура» »(ака Team Projects -> области & итераций) иерархии. К счастью, разрешения на создание только 1 уровень глубины (всегда хранятся в корневом каталоге Team Project), поэтому это не должно быть проблемой в вашем случае.