Jira实战 | 解决结果Resolution字段说明

最新推荐文章于 2023-08-18 16:56:46 发布

互联网PMO

最新推荐文章于 2023-08-18 16:56:46 发布

阅读量5.1k

点赞数 1

分类专栏： Atlassian社区

本文链接：https://blog.csdn.net/sinat_27030335/article/details/107377649

版权

Atlassian社区专栏收录该内容

40 篇文章 37 订阅

订阅专栏

什么是解决结果？

解决结果回答了：“问题关闭的原因是什么？”如果工作完成了，问题可能会被注记为"Done"或是"Fixed"；但如果问题和其他问题重复的情况，这个理由会被注记为"Duplicate"；又如果问题无法重现，解决结果可能会是"Won'tDo"或是"Won't Fix"，

尽量避免使较长的状态名称，如"Closed as Complete"或"Closedas a duplicate”。解决结果通常在问题"已解决"的情况下进行设置，问题的解决结果字段一般都是"未解决"，直到这个字段的值设置后，才会呈现"已解决"。

陷阱

有一家公司有太多的解决结果，以致于他们为特定项目创建自定义字段展示一个解决结果的子集。然后使用工作流的后处理功能来复制自定义的值到解决结果字段，自定义字段和解决结果的差异产生了前端和后端应用程序上的错误。公司应该限制解决结果的选项适用于所有的项目，而不是去解决这个问题。

建议

一旦问题被注记为“已解决”，你的用户将会访问你之前置放在工作流中的移转界面，或者，你可以使用后处理功能来自动设置解决结果，最好是能够让用户来设置适当的值，但是即使是通用的值如"Fixed"都好过关闭问题后呈现默认的"未解决"的值。

当问题重开的时候，可以使用工作流移转的后处理功能来清空“解决结果”字段的值。

批量更新解决结果

当清理混乱的情况，就像之前提到的例子，最好能够使用“批量变更”的功能，但是你不能够用这样的方法来更新问题的解决结果，这就表示你必须使用有点特殊和变通的策略来帮助你清理解决结果列表，每个策略都有优点和缺点，请慎重使用。

工作流转换

建一个临时性的工作流移转来使用后处理功能更新解决结果。

优点: 这个动作会留下审计的线索，因为变更会被记录在问题历史的一部分。
缺点: 你需要在每一个状态、每一个工作流之中创建一个新的移转和后处理功能，可以意味著有大量的手动工作，另外，每个变更都会产生大量的邮件通知。

第三方插件

你可以使用类似“ScriptRunner for JIRA”的插件来实现这件事情，这个插件具有"BulkFix Resolutions"的功能。

优点: 这个变更非常的快速，你不需要创建任何一个新的工作流的移转行为而且没有任何邮件通知。
缺点: 这个变更不会留下审计的痕迹，问题更新日期不会变更而且审计日志的不会有任何记录。

其它

虽然存在其它的选项，但是不推荐，这取决于问题的范围，可能是最好或是最容易地去修正新问题(issue)“遗漏的解决结果”的问题(problem)，并且保持既有的问题正常。

（1）在其它应用上去修正 (例如Excel)

导出有故障的问题，新添解决结果的值并且重新导入问题，"外部问题导入"的功能能够提供问题的更新，只要在其中提供单一键值去映射即可，或者，你可以导入到新的项目。

（2）向后转换

将问题向前移转到未解决的状况，在工作流的移转添加设置解决结果，并且将这些问题批量关闭或是将他们批量移转到适合的状态。

（3）数据库上直接更新

任何直接在数据库上变更的方法都是不建议的，如果你决定承担风险，至少这么做：

备份数据，
验证备份，
在非生产环境上完整地测试这个变更，
让数据库管理员待命，
有一个健全的回滚计划来防止任何意外的结果。

陷阱

有一家公司有34种解决结果的选项，其中包含特殊的选项如，"Rejected by Security Team"和"Rejectedby Finance Team"，此外，没有其他部分能拒绝请求的选项可选，许多的选项可能是不合理的。例如，问题呈现已解决的解决结果，怎么可能同时又处在“进行中(In Progress)”的状态？

有一家公司没有在工作流进行中设置解决结果，结果，不管问题状态如何，用户看到所有的问题都呈现在“分配给我”的仪表盘小工具上，这是因为小工具的查询假设所有结果结果呈现未解决的问题都是未完成的。