如何根据另一个字段的值禁止 TFS 要求工作项中的状态从“建议”更改为“活动”?
我已将部门批准添加到标准 CMMI 模板要求工作项中。我想限制 System.State 字段,以便只有当所有部门批准都设置为“是”时,才能将其从建议更改为有效。
我已尝试对 Requirement.xml 进行以下更改,
<FIELD name="State" refname="System.State" type="String" reportable="dimension">
<WHEN field="Approval.Marketing" value="No">
<READONLY />
</WHEN>
<WHEN field="Approval.Quality" value="No">
<READONLY />
</WHEN>
<WHEN field="Approval.RD" value="No">
<READONLY />
</WHEN>
<WHEN field="Approval.System" value="No">
<READONLY />
</WHEN>
<WHEN field="Approval.ProgManagement" value="No">
<READONLY />
</WHEN>
</FIELD>
这会导致 State 字段变为 READONLY,如果任何批准字段都设置为“否”,这就是我想要的。然而,在创建新需求时,它会导致问题,因为最初的批准全部为“否”,因此由于只读条件,状态的初始“建议”默认值并未设置。我想要做的是将逻辑添加到上面的 WHEN 条件中,并使用条件 System.State="Proposed" 来AND它们。我尝试嵌套 WHEN 子句,例如
<FIELD name="State" refname="System.State" type="String" reportable="dimension">
<WHEN field="System.State" value="Proposed">
<WHEN field="Approval.Marketing" value="No">
<READONLY />
</WHEN>
. . .
</WHEN>
</FIELD>
但这在导入时出现错误,WHEN 子句不能包含 WHEN。当任何批准字段设置为“否”时,如何禁止状态从建议更改为有效
I've added department approvals to the standard CMMI-Template Requirement work-item. I'd like to limit the System.State field such that it can only be changed from Proposed to Active when all department approvals are set to "Yes".
I've tried the following change to Requirement.xml
<FIELD name="State" refname="System.State" type="String" reportable="dimension">
<WHEN field="Approval.Marketing" value="No">
<READONLY />
</WHEN>
<WHEN field="Approval.Quality" value="No">
<READONLY />
</WHEN>
<WHEN field="Approval.RD" value="No">
<READONLY />
</WHEN>
<WHEN field="Approval.System" value="No">
<READONLY />
</WHEN>
<WHEN field="Approval.ProgManagement" value="No">
<READONLY />
</WHEN>
</FIELD>
This causes the State field to become READONLY if any of the approval fields are set to "No" which is what I want. However it causes problems when creating a new requirement since the approvals are all "No" initially and thus the initial "Proposed" default for State doesn't get set due to READONLY condition. What I'd like is to do is add logic to the WHEN conditions above to AND them with the condition System.State="Proposed". I tried nesting WHEN clauses such as
<FIELD name="State" refname="System.State" type="String" reportable="dimension">
<WHEN field="System.State" value="Proposed">
<WHEN field="Approval.Marketing" value="No">
<READONLY />
</WHEN>
. . .
</WHEN>
</FIELD>
But this gets an error on import that WHEN clause cannot contain WHEN. How can I prohibit State change from Proposed to Active when any of the Approval fields are set to "No"
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
我花了一些时间弄清楚是否可以想出一个可行的变体,因为您无法像其他字段那样为 System.State 设置默认值。在想出可行的方法之前,我可能经历了 50 种左右的变化。当然,它并不理想,但它可以在初始创建后解决您的问题。
您可以在每个过渡状态内添加 when 子句。对于我的示例,我使用优先级字段并执行以下操作:
当然,您必须将子句添加到其他状态:活动、关闭和已解决。
完成此操作后,创建一个新的需求。创建新需求时,您有两个选项:
您可以将所有选项设置为“是”,将状态设置为“建议”并保存。然后返回并将它们设置为否并保存。
或者
将您的自定义字段全部更改为默认为“是”。
创建需求并保存。编辑它,将所有值切换为否,保存。
无论您选择哪种方式,一旦随着需求创建克服了最初的障碍。它会按照您想要的方式行事。换句话说,如果任何值是 no,那么它将使状态变为只读。
考虑到 System.State 字段的限制,这是我能想到的最好的办法。
I spent some time figuring out if I could come up with a variation that would work since you cannot set a default value for System.State in the way you can other fields. I probably went through 50 or so variations before I came up with something that works. Granted, it is not ideal but it would solve your problem after the initial creation.
You could, inside each of the transition states, add your when clauses. For my example I was using the priority field and doing something like:
You would have to add your clauses of course to the other states: active, closed and Resolved.
Once you do that, create a new Requirement. When you create a new requirement you have two options:
You can either set all the options to yes, set state to proposed and save. Then go back and set them to no and save.
Or
Change your custom fields all to default to yes.
Create Requirement and save. Edit it, switch all the values to no, Save.
Either way you choose to go, once this initial hurdle is over with the requirement creation. It will act how you wanted it to. In other words, if any of the values are no then it will make state readonly.
That was the best I could come up with given the restriction for the System.State field.