【问题标题】:The call to BuildHttpClientBase.GetBuildWorkItemsRefsAsync doesn't return work items created by users with stakeholder access对 BuildHttpClientBase.GetBuildWorkItemsRefsAsync 的调用不会返回由具有利益相关者访问权限的用户创建的工作项
【发布时间】:2018-08-28 09:20:51
【问题描述】:

我正在使用Microsoft.TeamFoundationServer.Client Nuget package 来获取与某些构建相关联的工作项列表。为此,我使用以下代码:

using Microsoft.VisualStudio.Services.Common;
using Microsoft.VisualStudio.Services.WebApi;
using Microsoft.TeamFoundation.Build.WebApi;

public async Task<IEnumerable<ResourceRef>> GetBuildWorkItems(string vstsUrl, string teamProjectName, int buildId, string pat)
{
    VssConnection connection = new VssConnection(new Uri(vstsUrl), new VssBasicCredential(string.Empty, pat));
    using (var buildClient = connection.GetClient<BuildHttpClient>())
    {
        var workItems = await buildClient.GetBuildWorkItemsRefsAsync(teamProjectName, buildId);                
        return workItems;
    }
}

这很好用,除非工作项是由具有涉众访问级别的用户创建的。 GetBuildWorkItemsRefsAsync 方法不会特别返回这些工作项。

这是设计使然吗?我可以在 VSTS 管理员设置中配置有关利益相关者用户的内容,以免发生这种情况吗?

为了澄清,我在我的团队项目中使用 TFVC 而不是 Git。我不知道这是否与这个问题有关。

【问题讨论】:

  • 如果将构建链接到两个工作项,一个由 Stakeholder 用户创建,另一个由 Basic 用户创建并通过代码获取工作项,结果是什么?

标签: c# azure-devops azure-devops-rest-api


【解决方案1】:

试过GetBuildWorkItemsRefsAsync的方法,没发现问题。

但是,您可以简单地使用 REST API 来获取与特定构建关联的工作项列表:

GET https://{accountName}.visualstudio.com/{project}/_apis/build/builds/{buildId}/workitems?api-version=4.1

详情请见Builds - Get Build Work Items Refs

以PowerShell为例:

Param(
   [string]$collectionurl = "https://{account}.visualstudio.com",
   [string]$project = "ProjectName",
   [string]$BuildID = "283",
   [string]$user = "username",
   [string]$token = "password"
)

# Base64-encodes the Personal Access Token (PAT) appropriately
$base64AuthInfo = [Convert]::ToBase64String([Text.Encoding]::ASCII.GetBytes(("{0}:{1}" -f $user,$token)))

$WITbaseUrl = "$collectionurl/$project/_apis/build/builds/$($BuildID)/workitems"

#Response           
$WITresponse = (Invoke-RestMethod -Uri $WITbaseUrl -Method Get -Headers @{Authorization=("Basic {0}" -f $base64AuthInfo)}).value

$WITrequests = @()

foreach($WITrequest in $WITresponse){

    $customObject = new-object PSObject -property @{
          "WorkitemID" = $WITrequest.id
          "WorkitemURL" = $WITrequest.url
        } 

    $WITrequests += $customObject       
}

$WITrequests | Select `
               WorkitemID,
               WorkitemURL

【讨论】:

  • 感谢您的回复。我没有使用 PoweShell,而是使用 Postman 来调用 REST API。结果是一样的。基本上我做了两个测试:一个带有一个 buildId,它链接了由具有利益相关者访问级别的用户创建的工作项;第二个测试的 buildId 是由具有 Visual Studio Enterprise Subscription 访问级别的用户创建的链接工作项。第一个测试返回一个空的工作项列表(这是返回的 json: {"count": 0, "value": []}),而第二个测试返回正确的链接工作项。你有更多建议吗?
  • @DuarteSilva 您使用哪个用户来运行 REST API?利益相关者用户没有查看构建的权限,这可能是根本原因。
  • 抱歉,我不清楚这一点。我创建了一个与我的用户关联的个人访问令牌(具有 Visual Studio Enterprise Subscription 访问级别),并且在我描述的每个测试中都使用了该 PAT。该 PAT 的授权范围是构建(读取)和工作项(完整)。在这种情况下我需要更多范围吗?
  • @DuarteSilva 没有别的了,范围应该没问题。但我无法重现我这边的问题。我可以看到所有相关的工作项,即使它们是由利益相关者用户创建的。您能从构建摘要页面中看到相关的工作项吗?
  • 是的,我可以在构建摘要页面上看到相关的工作项。我开始怀疑自己是不是在做一些完全愚蠢的事情......
猜你喜欢
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
  • 1970-01-01
相关资源
最近更新 更多