User Permissions in TFS API - Start a Build, Administer a Build

Question

I am looking for a way to find out if a user has the "Start a Build" permission for a given project.

As of now, I know that the VersionControlServer object can be used to return a string array of the user's effective permissions within a project. But, when I run the GetEffectivePermissions method on the VersionControlServer, the "Start a Build" and "Administer a Build" permissions are not included in the array that lists the user's permissions.

I am assuming (incorrectly?) that this is because I am querying a VersionControlServer, which does not control build permissions.

How would I find the user's effective "build-related" permissions via the TFS 2008 API?

Answer 1

Unfortunately, Team Build does not have a full-blown client object model like Version Control. It's MUCH better in 2008, but it still lacks its own security API. So you have to step down a level to the more basic webservice interfaces offered server-wide:

• IAuthorization
• ICommonStructure
• IGroupSecurity

Here's a quick demo in 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 }
    }

Unfortunately, with this low level API there is no one-stop shopping for "effective permissions." The Auth service can resolve various ACEs that apply to a user via multiple group membership, as well as a limited form of parent->child inheritance, but I don't think it knows about the version control hierarchy -- only the "common structure" (aka Team Projects -> areas & iterations) hierarchy. Luckily, build permissions are only 1 level deep (always stored @ the Team Project root) so this shouldn't be an issue in your case.