4

当您在 Azure devops 中创建诸如 Bug 之类的工作项时,您将在“原因”字段的下拉列表中看到的值将取决于您为“状态”字段选择的值。例如,请参阅这些屏幕截图(模板敏捷,无自定义)

基于状态字段的允许值

然后,如果您更改状态,则允许的值会更改,如图所示

在此处输入图像描述

更令人困惑的是,这些只是记录的 REST API 返回的几个值

给定的 API 返回

 "defaultValue": null,
        "allowedValues": [
          "Verified",
          "Not fixed",
          "Test Failed",
          "As Designed",
          "Cannot Reproduce",
          "Copied to Backlog",
          "Deferred",
          "Duplicate",
          "Fixed and verified",
          "Obsolete",
          "Fixed",
          "Investigation Complete",
          "Approved",
          "Investigate",
          "Resolved in error",
          "Reactivated",
          "Regression",
          "Build Failure",
          "New"
        ],
        "helpText": "The reason why the bug is in the current state",
        "alwaysRequired": false,
        "dependentFields": [
          {
            "referenceName": "System.State",
            "name": "State",
            "url": "https://dev.azure.com/nikhil/_apis/wit/fields/System.State"
          },
          {
            "referenceName": "Microsoft.VSTS.Common.ResolvedReason",
            "name": "Resolved Reason",
            "url": "https://dev.azure.com/nikhil/_apis/wit/fields/Microsoft.VSTS.Common.ResolvedReason"
          }
        ],
        "referenceName": "System.Reason",
        "name": "Reason",
        "url": "https://dev.azure.com/{project}/{templateid}/_apis/wit/fields/System.Reason"
      },

我试图找出正确的 API 或一组 API,以帮助揭开何时显示组合框中的内容、何时将它们标记为只读以及何时让用户编辑它们的神秘面纱。

解决的原因字段更有趣。对于大多数部分来说,它似乎只是简单地复制了 Reason 字段中的值,但是 Rules API(见下文)并没有表明这种行为。看起来规则 API 返回的内容与该字段显示的行为不匹配。

这里的 REST API 中提到了一个规则的概念 - https://docs.microsoft.com/en-us/rest/api/azure/devops/processes/rules/get?view=azure-devops-rest-5.1 #进程规则

但是,这似乎并没有给出根据我上面解释的另一个字段的值专门控制字段的“allowedValues”的规则。

问题:

  1. 是否有一个 API 可以为工作项类型上的字段(包括其 allowedValues)提供一套全面的规则?例如,原因或已解决的原因字段取决于状态字段的选择,如上所示?
4

2 回答 2

2

是否有一个 API 可以为工作项类型上的字段(包括其 allowedValues)提供一套全面的规则?例如,原因或已解决的原因字段取决于状态字段的选择,如上所示?

首先,我需要说,不,没有这样的 REST API 来获取Reason取决于State所选字段的值。由于这些都没有记录,我们验证它的最佳方法是使用Fiddler 跟踪(Fiddler 可以记录 Web 应用程序和 Internet 之间的所有 Internet 数据)。


[例如,这里我将使用Bug工作项来说明。]

首先,清除 Fiddler 中的所有记录 => 打开 Azure Devops 中的 Bug 工作项 => 在 Fiddler 中按 F12 开始记录数据。

在 Azure Devops 中更改工作项状态(注意:只是更改,不要保存。“保存”属于另一个操作)。然后去 Fiddler 看看它的上网记录:

在此处输入图像描述

你会看到只有 2 个事件 API,这些 API 只用于发布动作标志而不是操作它。查看第一个POST Event API 的请求正文:

在此处输入图像描述

你可以看到它刚刚用来张贴一个关于State字段的标志已经改变了。这就是为什么我说没有 API 来获取Reason取决于所State选择的字段的值,因为我们的开发团队没有使用带有 API 的脚本来实现这一点。


现在,您应该非常困惑该操作消息要发送给谁?既然列出的 Reason 字段值不受 api 控制,那么谁在控制?

答案是XML 流程模板

在 Azure Devops 中,WIT 都是由 XML 模板控制的。您可以找到所有规则,例如Reason列出的字段值取决于State更改的字段,从原因字段复制值等。

我已经将Bug.xml流程模板上传到我的github,您可以参考该代码进行分析:Agile-process/Bug.xml

对于Reason列出的字段值取决于State更改的字段。

  <FIELD name="Resolved Reason" refname="Microsoft.VSTS.Common.ResolvedReason" type="String" reportable="dimension">
    <ALLOWEDVALUES>
      <LISTITEM value="As Designed" />
      <LISTITEM value="Cannot Reproduce" />
      <LISTITEM value="Deferred" />
      <LISTITEM value="Duplicate" />
      <LISTITEM value="Fixed" />
      <LISTITEM value="Fixed and verified" />
      <LISTITEM value="Obsolete" />
      <LISTITEM value="Copied to Backlog" />
    </ALLOWEDVALUES>
    <HELPTEXT>The reason why the bug was resolved</HELPTEXT>
  </FIELD>

这些是控制列出的已解决原因的 xml 代码。我相信你已经明白了它的逻辑。我们从 fiddler 得到的 event API 的消息是由相关的 WIT 得到的*.xml。然后相应的操作将被触发并执行。

在此处输入图像描述

用于复制原因字段中的值。

    <TRANSITION from="New" to="Resolved">
      <ACTIONS>
        <ACTION value="Microsoft.VSTS.Actions.Checkin" />
      </ACTIONS>
      <REASONS>
        <DEFAULTREASON value="Fixed">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <COPY from="value" value="Fixed" />
              <ALLOWEDVALUES>
                <LISTITEM value="Fixed" />
              </ALLOWEDVALUES>
            </FIELD>
          </FIELDS>
        </DEFAULTREASON>
        <REASON value="Deferred">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <COPY from="value" value="Deferred" />
              <ALLOWEDVALUES>
                <LISTITEM value="Deferred" />
              </ALLOWEDVALUES>
            </FIELD>
          </FIELDS>
        </REASON>
        <REASON value="Duplicate">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <COPY from="value" value="Duplicate" />
              <ALLOWEDVALUES>
                <LISTITEM value="Duplicate" />
              </ALLOWEDVALUES>
            </FIELD>
          </FIELDS>
        </REASON>
        <REASON value="As Designed">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <COPY from="value" value="As Designed" />
              <ALLOWEDVALUES>
                <LISTITEM value="As Designed" />
              </ALLOWEDVALUES>
            </FIELD>
          </FIELDS>
        </REASON>
        <REASON value="Cannot Reproduce">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <COPY from="value" value="Cannot Reproduce" />
              <ALLOWEDVALUES>
                <LISTITEM value="Cannot Reproduce" />
              </ALLOWEDVALUES>
            </FIELD>
          </FIELDS>
        </REASON>
        <REASON value="Obsolete">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <COPY from="value" value="Obsolete" />
              <ALLOWEDVALUES>
                <LISTITEM value="Obsolete" />
              </ALLOWEDVALUES>
            </FIELD>
          </FIELDS>
        </REASON>
        <REASON value="Copied to Backlog">
          <FIELDS>
            <FIELD refname="Microsoft.VSTS.Common.ResolvedReason">
              <COPY from="value" value="Copied to Backlog" />
              <ALLOWEDVALUES>
                <LISTITEM value="Copied to Backlog" />
              </ALLOWEDVALUES>
            </FIELD>
          </FIELDS>
        </REASON>
      </REASONS>
      <FIELDS>
        <FIELD refname="System.AssignedTo">
          <COPY from="field" field="System.CreatedBy" />
        </FIELD>
        <FIELD refname="Microsoft.VSTS.Common.ActivatedDate">
          <SERVERDEFAULT from="clock" />
        </FIELD>
        <FIELD refname="Microsoft.VSTS.Common.ActivatedBy">
          <COPY from="currentuser" />
          <VALIDUSER />
          <REQUIRED />
        </FIELD>
        <FIELD refname="Microsoft.VSTS.Common.ResolvedBy">
          <COPY from="currentuser" />
          <VALIDUSER />
          <REQUIRED />
        </FIELD>
        <FIELD refname="Microsoft.VSTS.Common.ResolvedDate">
          <SERVERDEFAULT from="clock" />
        </FIELD>
      </FIELDS>
    </TRANSITION>

这只是关于从Bug工作项xml文件的原因字段中复制值的一小部分。

事实上,您可以从这些 XML 文件中找到 API 无法获取的所有流程规则(注意:我只是指默认流程规则)。如果你愿意,我可以在我的 github 中分享完成的流程 XML 文件。

希望这可以更清楚地帮助您:-)

于 2019-09-16T15:09:55.410 回答
0

是否有一个 API 可以为工作项类型上的字段提供一套全面的规则,包括根据 State 字段的选择,说 Reason 字段的 allowedValues?

对于这个问题,您可以使用Rules-List api 来获取。

GET https://dev.azure.com/{organization}/_apis/work/processes/{processId}/workItemTypes/{witRefName}/rules?api-version=5.1-preview.2

我用 postman 测试,下图是我测试返回的结果。

在此处输入图像描述

通过搜索关键字,我们可以根据 State 字段的选择获得 Reason 字段的允许值规则。

api中需要的processId参数可以通过这个rest api获取。

希望这可以帮助。

于 2019-09-04T09:19:54.707 回答