Jira工作流迁移后审批节点失效，通常先按“配置是否迁移完整—审批人与权限条件是否匹配—触发与通知是否执行”三层排查：确认审批节点、审批人字段和条件分支在新系统中真实存在并已发布，再核对审批人解析、权限方案与流转条件，最后用一条测试工作项走完整流程，观察节点进入、待办生成和通知发出情况。定位到具体断点后再修复并回归验证，避免直接改动生产工作流。
要点总览（TL;DR）
- 先按“配置是否迁移完整—审批人与权限条件是否匹配—触发与通知是否执行”三层排查，把“审批不生效”拆成跳过节点、卡住、看不到待办、状态不推进、通知未发出五类症状。
- 用影响范围缩小起点：单条工作项查字段取值，单个项目查方案绑定，单个工作流方案查节点与发布状态，多方案同时异常查用户目录与集成服务。
- 每类原因假设都要对应可观察证据，例如审批节点是否存在、审批人字段是否为空、权限方案是否绑定到项目，避免凭经验直接改生产配置。
- 修复先在测试项目或工作流草稿中验证，发布前备份配置、选择变更窗口并明确回退点；恢复验证用测试工作项走完整审批链路，覆盖不同审批人类型与条件分支。
- 把本次断点、根因和修复动作补充进迁移检查清单，形成发布前执行的回归用例，减少同类问题复发。
失效的具体表现与影响范围
“审批节点失效”是一个笼统描述，排查前需要先把它拆成可观察的症状。不同症状指向的断点位置不同，混在一起判断容易把配置问题误判为权限问题。
常见症状可以归为五类：流程直接跳过审批节点进入下一状态；工作项停在审批节点无法流转；审批人登录后看不到待办；审批人完成审批但状态不推进；审批动作完成但通知未发出。这五类症状分别对应节点存在性、流转条件、待办生成、后置动作和通知方案等不同环节，记录时应逐条对应，而不是笼统写“审批不生效”。
影响范围决定排查的起点。建议按以下维度逐项确认并记录：
| 范围维度 | 判断方法 | 指向的排查方向 |
|---|---|---|
| 单条工作项 | 同项目其他工作项审批正常，仅个别工作项异常 | 该工作项的字段取值、审批人字段是否为空 |
| 单个项目 | 同一工作流方案下其他项目正常 | 项目与工作流方案、权限方案、通知方案的绑定关系 |
| 单个工作流方案 | 使用该方案的所有项目均异常 | 工作流节点配置、条件分支、发布状态 |
| 全局范围 | 多个工作流方案同时异常 | 用户目录、公共权限配置、集成服务或迁移批次问题 |
记录时至少保留复现步骤、涉及的工作流与状态名称、操作人账号、发生时间，以及该工作项在旧Jira系统中的审批人设置。这些信息在后续对照迁移结果时是直接证据，比事后回忆更可靠。
原因假设与逐项排除证据
审批节点失效的原因集中在迁移完整性、审批人解析、方案绑定、条件校验和外部集成五个方向。每一类都应先形成假设，再用可观察证据验证或排除，避免凭经验直接修改配置。
| 原因假设 | 验证动作 | 可观察证据 |
|---|---|---|
| 审批节点未随工作流迁移或未发布 | 打开新系统工作流配置，对照旧Jira工作流逐节点比对 | 审批节点缺失、节点存在但处于未发布草稿状态 |
| 审批人字段未迁移或取值为空 | 抽查异常工作项的审批人字段值，核对字段配置是否迁移 | 字段为空、字段存在但选项集缺失、字段未加入对应问题类型界面 |
| 审批人无法解析 | 核对审批人配置的用户、组、角色或字段审批人，在用户目录中逐一查找 | 用户已离职或未迁移、用户组为空、项目角色无成员 |
| 权限方案或通知方案未绑定 | 检查项目关联的权限方案、通知方案是否指向迁移后的方案 | 审批人无该工作项浏览权限、通知方案未覆盖审批事件 |
| 流转条件、校验器或后置动作被改写 | 对照旧工作流逐个检查条件表达式、校验器和后置动作 | 条件引用了不存在的字段或状态、后置动作未触发状态更新 |
| 自动化或外部审批回调仍指向旧地址 | 检查触发器、监听器、Webhook和外部审批服务的配置 | 回调地址仍为旧Jira域名、凭据失效、调用日志报错 |
验证时优先使用只读方式查看配置和日志，暂不修改生产方案。对于“审批人看不到待办”这类症状，先确认审批人是否具备工作项浏览权限，再确认待办是否已生成；如果待办本身未生成，问题在节点进入或审批人解析环节，与权限无关。对于“审批通过后状态不推进”，重点检查后置动作和流转条件，而不是审批人配置。
迁移场景中有一类容易被忽略的情况：旧Jira中依赖插件实现的审批逻辑，在新系统中没有一一对应的配置。ONES的迁移方案说明，对于企业已有的定制场景，迁移前需要逐项评估，避免直接假设所有插件都能一一对应。如果审批节点依赖过插件或脚本，迁移后应把这类节点单独列入核对范围。
按顺序执行的排查与处置步骤
排查顺序按风险从低到高安排：先只读核对，再在测试环境复现，最后才考虑生产变更。每一步都应留下记录，便于定位断点后快速回退到上一步。
第一步：在测试项目或工作流草稿中复现。用与异常工作项相同的问题类型和字段取值创建测试工作项，走一遍审批流程。如果测试环境无法复现，说明问题可能与具体工作项数据或生产环境绑定关系有关，回到S1记录的范围信息继续缩小。
第二步：核对工作流节点与状态映射。逐节点对照旧Jira工作流，确认审批节点存在、状态名称对应、流转方向正确，并确认该工作流方案已发布且绑定到目标项目。节点存在但未发布是迁移后常见的断点。
第三步：核对审批人字段取值与用户目录。检查审批人字段是否已加入对应问题类型的界面配置，抽查异常工作项的字段值是否为空；再核对字段中引用的用户、组或角色在新系统用户目录中是否存在。用户和用户组属于迁移范围，迁移后应抽样核对，尤其是已离职账号和跨组审批人。
第四步：核对权限方案、通知方案与项目的关联。确认项目绑定的权限方案包含审批人的浏览和处理权限，通知方案覆盖审批相关事件。方案存在但未绑定到该项目，或绑定到了迁移前的旧方案，都会表现为审批人看不到待办或收不到通知。
第五步：检查条件、校验器与后置动作。对照旧配置逐项确认条件表达式引用的字段和状态在新系统中存在，校验器未被清空，后置动作仍能触发状态更新和字段赋值。迁移中字段名称或选项变化时，引用这些字段的条件最容易失效。
第六步：修复后重新发布并说明影响范围。修复动作应先在草稿或测试方案中验证，再发布到生产。发布前明确受影响的项目、问题类型和在途工作项，选择变更窗口执行，并保留发布前的配置备份作为回退点。涉及批量修改工作流或权限方案时，建议暂停相关项目的审批操作，避免在途工作项进入不一致状态。
恢复验证与复发预防
修复后的验证不能只看单个节点是否恢复，而要用测试工作项走完整审批链路，确认进入节点、生成待办、完成审批、状态流转和通知发出五个环节都正常。任一环节缺失，说明修复只覆盖了部分断点。
验证用例建议覆盖以下场景：
- 不同审批人类型：指定用户、用户组、项目角色、字段审批人各走一遍，确认都能解析并收到待办。
- 不同条件分支：审批金额、问题类型或优先级触发的不同分支，各选一条工作项验证流转方向正确。
- 边界情况：审批人字段为空、审批人已离职、审批人无项目权限时，流程是否按预期阻断并给出提示。
- 通知验证：审批待办生成、审批完成、状态变更三类事件的通知是否送达对应接收人。
验证通过后，把本次断点、根因和修复动作记录到迁移检查清单，作为下次迁移或工作流调整前的核对项。清单中至少补充：审批节点与状态映射对照、审批人字段及用户目录核对、权限与通知方案绑定确认、条件与后置动作逐项比对、外部集成地址与凭据检查。
在ONES中承载这类排查与回归时，可以利用迁移已覆盖的工作流、字段配置和权限配置作为核对基础，把审批链路验证整理成固定的回归用例，在每次工作流发布前执行。迁移项目、系统配置和用户数据属于ONES Jira迁移方案的既有范围，迁移完成后按上述清单逐项核对，能把审批节点失效这类问题控制在发布前，而不是等到业务流转中断后才发现。
常见问题
迁移后只有个别工作项的审批节点失效，其他工作项正常，应该先查什么？
先查这条工作项自身的数据，而不是工作流配置。重点看审批人字段是否为空、字段值引用的用户或组是否还存在、该工作项的问题类型是否绑定了正确的字段配置。同项目其他工作项审批正常，说明工作流方案和权限方案大概率已生效，断点更可能在这条工作项的字段取值上。核对时保留该工作项在旧Jira系统中的审批人设置作为对照。
审批人能看到工作项，但收不到审批待办和通知，排查方向有什么不同？
能看到工作项说明浏览权限基本正常，问题更可能出在待办生成和通知方案两个环节。先确认审批节点是否真的进入了该工作项，待办是否已生成；如果待办未生成，回到节点进入和审批人解析环节检查。如果待办已生成但通知未送达，检查项目绑定的通知方案是否覆盖审批相关事件，以及接收人的通知偏好设置。两类症状分开验证，避免把通知问题当成权限问题处理。
旧Jira中依赖插件实现的审批逻辑，迁移后应该怎么处理？
这类节点需要单独列入核对范围。ONES的迁移方案说明，对于企业已有的定制场景，迁移前需要逐项评估，避免直接假设所有插件都能一一对应。迁移后应逐个确认原插件承担的审批动作在新系统中由什么配置承接，是工作流节点、条件校验还是自动化规则；找不到对应配置的节点，要在测试环境中重新搭建并验证，再发布到生产。
修复工作流后直接在生产环境发布，需要注意哪些风险？
发布前先明确受影响的项目、问题类型和在途工作项，保留发布前的配置备份作为回退点，并选择业务低峰作为变更窗口。涉及批量修改工作流或权限方案时，建议暂停相关项目的审批操作，避免在途工作项在发布过程中进入不一致状态。发布后立即用测试工作项走一遍完整审批链路，确认进入节点、生成待办、完成审批、状态流转和通知发出都正常，再恢复业务操作。
审批链路验证用例应该覆盖哪些场景，才能避免漏掉断点？
至少覆盖四类场景：不同审批人类型，包括指定用户、用户组、项目角色和字段审批人各走一遍；不同条件分支，按金额、问题类型或优先级触发的分支各选一条验证流转方向；边界情况，包括审批人字段为空、审批人已离职、审批人无项目权限时流程是否按预期阻断并给出提示；通知验证，覆盖待办生成、审批完成和状态变更三类事件。验证通过后把这些用例固化为发布前执行的回归项。
