4. 条件与验证器深入

在 Jira 工作流中，条件（Condition）决定“谁能看到并执行某个动作”，验证器（Validator）决定“执行动作时提交的数据是否合法”。两者作用时机不同：条件在动作按钮渲染前评估，验证器在用户点击提交后、工作流真正流转前评估。理解这一先后关系，是组合使用它们的前提。

本节聚焦三类常用条件——脚本条件、用户条件、权限条件，以及字段必填验证器的组合应用。它们共同构成工作流“入口控制 + 数据校验”的双层防线。

一、三类条件的定位与差异

用户条件（User Is In Group / User Is In Project Role）是最直观的一类：判断当前用户是否属于指定用户组或项目角色。例如“仅项目角色 Administrators 可执行关闭”，配置时选择角色即可，无需写代码。它的优点是稳定、易维护，缺点是只能做“成员归属”判断，无法表达“当前用户是否为经办人”“是否为报告人”这类动态关系。

权限条件（Permission Condition）基于 Jira 全局权限方案判断，例如“只有拥有 Resolve Issues 权限的用户才能执行解决”。它把控制权交给权限方案统一管理，适合与组织级权限策略保持一致。注意：权限条件依赖权限方案配置，若权限方案被改动，工作流行为会随之变化，因此变更权限方案时需回归测试相关转换。

脚本条件（Script Condition）通过 Groovy 脚本实现任意逻辑，是三者中最灵活也最需要谨慎使用的。它适合表达“经办人本人且优先级为 Highest”“自定义字段‘审批状态’等于 Approved”等复合判断。脚本条件必须返回布尔值，返回 true 表示条件满足、动作可见。

二、脚本条件的编写要点

脚本条件运行在 Jira 的脚本引擎中，可访问 issue、currentUser、componentManager 等绑定变量。一个典型场景是“仅经办人本人可执行‘提交复核’”：

// Script Condition: 仅经办人本人可提交复核
def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def assignee = issue.assignee
return assignee != null && assignee.name == currentUser.name

若需叠加字段判断，可写成：

// 经办人本人 且 优先级为 Highest 才可提交复核
def cu = ComponentAccessor.jiraAuthenticationContext.loggedInUser
def isAssignee = issue.assignee?.name == cu.name
def isHigh = issue.priority?.name == "Highest"
return isAssignee && isHigh

编写脚本条件时需注意三点：第一，空值防护，assignee、priority 等字段可能为空，必须用 ?. 或显式判空，否则脚本抛异常会导致动作不可见甚至报错；第二，性能，条件会在每次渲染动作时执行，避免在脚本中做全库查询；第三，可读性，把复杂逻辑拆成多个布尔变量并加注释，便于后续维护。

三、字段必填验证器的组合应用

验证器中最常用的是字段必填验证器（Field Required Validator），它确保转换执行时指定字段已有值。常见配置包括：解决结果必填、经办人必填、自定义字段“复核意见”必填等。

验证器可以叠加多个，形成“与”关系：所有验证器都通过，转换才执行。例如“提交复核”转换可同时挂载：

• Field Required Validator：字段 = 经办人
• Field Required Validator：字段 = 优先级
• Field Required Validator：字段 = 复核意见（自定义字段）

当用户点击提交时，Jira 会依次执行验证器，任一失败即阻止转换，并在页面上给出对应错误提示。验证器失败不会改变工作流状态，用户可修正后重新提交。

四、条件与验证器的组合策略

条件与验证器常配合使用，形成“先控制可见性，再校验数据”的链路。以“提交复核”转换为例：

• 条件层：脚本条件判断“经办人本人且优先级为 Highest”，不满足则按钮不可见；
• 验证器层：字段必填验证器确保“复核意见”已填写；
• 结果：只有经办人本人、优先级为 Highest、且填写了复核意见时，转换才能成功。

这种组合的价值在于：条件层减少无效操作入口，验证器层保证数据完整，二者互补。若只加验证器不加条件，任何用户都能看到按钮但提交失败，体验差；若只加条件不加验证器，满足条件的用户可能提交空数据，导致后续流程缺字段。

五、配置示例与结果判断

下表给出“提交复核”转换的完整配置示例，便于对照实施：

验证方式：用不同用户登录，分别验证按钮可见性与提交结果。例如，非经办人登录时按钮不可见；经办人但优先级为 Medium 时按钮不可见；经办人且优先级 Highest 但未填复核意见时，提交被拦截并提示“复核意见为必填”。只有全部满足时，转换成功、状态变为“待复核”。

排障时优先检查：条件脚本是否抛异常（查看日志）、验证器字段是否与屏幕配置一致、权限方案是否被改动。条件与验证器的组合不是越多越好，应围绕“谁可以操作”和“操作必须带什么数据”两个问题精简配置，避免过度约束导致流程卡死。

综上，条件与验证器的组合应用，核心是分清“可见性控制”与“数据校验”两个层次：条件用用户条件、权限条件或脚本条件控制入口，验证器用字段必填验证器保证数据完整。配置时保持精简、可读、可回归，才能让工作流既安全又顺畅。