📚 课程目录第2章 Jira工作流核心模型

2. Jira工作流核心模型

在 Jira 中，工作流并不是一张“好看的流程图”，而是一套由五类核心元素共同驱动的状态机：状态（Status）定义问题当前处于哪个阶段，转换（Transition）定义从哪个状态可以走到哪个状态，条件（Condition）决定“谁能看到并执行这个转换”，验证器（Validator）决定“执行前必须满足什么”，后置函数（Post Function）决定“执行后系统自动做什么”。理解这五者的分工，是后续做工作流定制、权限控制和自动化扩展的基础。

一、状态：问题的“当前位置”

状态是工作流中最直观的部分，例如“待办（To Do）”“处理中（In Progress）”“待验证（In Review）”“已完成（Done）”。状态本身只描述位置，不描述动作。一个常见误区是把“已关闭”和“已完成”混为一谈：如果业务上需要区分“开发完成”和“客户验收通过”，就应拆成两个状态，而不是用一个状态加备注来区分。

状态还分为初始状态和结束状态。新建问题时进入初始状态；进入结束状态后，问题通常不再出现在活跃看板中。Jira 允许一个工作流有多个结束状态，例如“已完成”“已取消”“重复”，它们对报表统计的意义不同，建议在方案设计阶段就明确。

二、转换：状态之间的“有向边”

转换是状态之间的连接线，它有三个关键属性：起点状态、终点状态、转换名称。转换名称会出现在用户点击的按钮上，例如“开始处理”“提交评审”“驳回”。同一个起点和终点之间可以存在多条转换，例如“处理中 → 待验证”可以同时有“提交评审”和“直接完成”两条路径，分别绑定不同的条件和验证器。

转换还支持全局转换，即不限定起点状态、从任意状态都能触发的转换，典型场景是“关闭问题”。全局转换方便，但容易绕过流程约束，建议只在确实需要“随时可关闭”的场景使用，并配合验证器限制权限。

三、条件、验证器、后置函数：转换上的三类钩子

这三者都挂在转换上，但执行时机和作用完全不同，可以用一句话区分：条件管“能不能点”，验证器管“能不能过”，后置函数管“过了之后做什么”。

条件：在用户打开问题页面时评估，决定转换按钮是否可见。例如“仅经办人可以开始处理”，用 Only Assignee Condition 实现。条件不满足时按钮直接隐藏，用户看不到入口。
验证器：在用户点击转换、提交表单时评估，决定这次转换是否被接受。例如“提交评审前必须填写‘评审人’字段”，用 Field Required Validator 实现。验证失败会弹出错误提示，转换不执行。
后置函数：在转换成功写入后按顺序执行，用于自动改字段、分配经办人、发通知、触发脚本。例如“开始处理”时自动把经办人设为当前用户，并记录开始时间。

记忆口诀：条件决定“看不看得见”，验证器决定“点不点得动”，后置函数决定“点完之后系统替你做什么”。

四、一个可落地的转换配置示例

假设“缺陷（Bug）”工作流中有一条转换“提交评审”，从“处理中”到“待验证”。可以这样配置：

转换名称：提交评审
起点状态：处理中
终点状态：待验证

条件：
  - Only Assignee Condition（仅经办人可见）

验证器：
  - Field Required Validator → 字段：评审人
  - Field Required Validator → 字段：修复版本

后置函数（按顺序）：
  1. Update Issue Field → 经办人 = 评审人
  2. Update Issue Field → 评审开始时间 = %%CURRENT_DATETIME%%
  3. Fire Event → 触发“问题已更新”事件，通知评审人

执行顺序很重要：后置函数按列表从上到下运行，如果第 1 步把经办人改成了评审人，第 3 步的通知就会发给新的经办人。若顺序颠倒，通知可能仍发给原经办人。因此配置后置函数时，务必确认“谁在什么时候被改变”。

五、工作流方案与项目关联

工作流本身是独立实体，不能直接“贴”到项目上。Jira 通过工作流方案（Workflow Scheme）建立映射：一个方案里可以为不同问题类型指定不同的工作流。例如同一个项目中，“缺陷”用缺陷工作流，“任务”用任务工作流，“子任务”用子任务工作流。

项目与工作流方案是多对一关系：多个项目可以共用同一个方案，但一个项目在同一时间只能绑定一个方案。修改方案会影响所有绑定它的项目，因此变更前要评估影响范围。Jira 提供“草稿工作流”和“方案迁移”能力：可以先在草稿中修改，再发布并选择是否迁移历史问题，避免直接改动线上流程导致状态错乱。

六、配置时的常见判断点

第一，条件与验证器的边界：如果某类用户根本不应该看到这个操作，用条件；如果所有人都能看到但只有部分人能提交，用验证器。第二，后置函数的幂等性：例如“累加字段”类后置函数在重复触发时会重复累加，需要配合条件或脚本判断。第三，方案变更的影响面：修改共用方案前，先在工作流方案页面查看“被哪些项目使用”，必要时先复制方案再改，避免影响其他团队。

把状态、转换、条件、验证器、后置函数这五层关系理清，再通过工作流方案与项目建立映射，就能在不破坏历史数据的前提下，逐步把通用流程演进为贴合团队实际协作方式的定制流程。