替换 Jira 后，原插件承载的字段、权限和自动化最容易在迁移后出现断点。排查时先按症状把问题归入这三类并锁定影响范围，再按“先数据、后权限、最后自动化”的顺序推进：确认字段与选项值是否迁到，核对角色与字段级权限是否重建，检查自动化规则的触发事件、条件与执行身份是否成立。每一步都以可观察证据判断，未确认前不把假设当结论。
要点总览（TL;DR）
- 先按症状把断点归入字段、权限、自动化三类，用3到5个代表性工作项锁定影响范围，再按“先数据、后权限、最后自动化”的顺序推进。
- 字段断点先区分字段不存在、字段存在但值为空、选项不完整、字段未加入界面方案四种情形，抽样比对原系统字段值是最直接的证据。
- 权限断点从项目可见性查起，依次核对角色成员映射、字段级可见与编辑权限、工作流条件限制，用不同角色账号复现同一操作可避免误判为数据丢失。
- 自动化断点逐条核对规则是否存在、触发事件是否命中、条件字段是否有效、执行身份是否有权限、动作结果是否符合预期，执行日志是关键证据。
- 修复时先补数据再调权限最后改自动化，批量修改前备份或留快照，用原复现样本回归并建立字段、权限、规则对照清单防止复发。
断点出现在哪一层：字段、权限还是自动化
迁移后的异常往往同时表现为“看不到数据”“改不了状态”“规则没反应”，如果混在一起查，容易把权限问题误判成数据丢失，或把字段缺失误判成自动化失效。第一步的任务是归类，而不是修复。
三类断点的典型症状
| 断点类型 | 典型症状 | 容易混淆的现象 |
|---|---|---|
| 字段 | 工作项上字段缺失、字段存在但值为空、下拉选项不完整、历史值显示异常 | 用户说“看不到某字段”，实际是字段未加入界面方案 |
| 权限 | 同一工作项部分人可见、部分人不可见；能查看但不能编辑；状态流转按钮不出现 | 被误判为数据未迁移或字段丢失 |
| 自动化 | 规则不触发、触发后无动作、动作结果与预期不符、执行记录报错 | 被误判为字段值错误，实际是条件引用了已变更的字段 |
用少量样本工单锁定影响范围
从用户反馈中挑 3 到 5 个代表性工作项作为复现样本，覆盖不同项目、不同工作项类型和不同角色。对每个样本记录：涉及哪些项目、哪些字段或规则、由哪个账号操作、期望结果与实际结果。样本要能区分“单点问题”和“批量问题”——如果同一字段在所有项目中都为空，倾向迁移或配置层面的问题；如果只在某个项目或某个角色下出现，倾向权限或界面方案问题。
总体排查顺序原则
遵循三条原则：先数据后权限再自动化，因为权限判断依赖字段是否存在、自动化条件依赖字段值是否有效；先单点复现再批量验证，避免在原因未明时批量改动扩大影响；每一类断点内部也按“是否存在→配置是否完整→是否生效”的层次推进。下表可作为排查过程中的记录表使用。
| 症状描述 | 涉及项目 | 涉及字段/规则 | 复现样本 | 初步归类 |
|---|---|---|---|---|
| 示例：需求类型工作项“客户等级”为空 | 项目 A | 客户等级字段 | 工作项 A-102 | 字段 |
| 示例：测试角色看不到“严重程度” | 项目 B | 严重程度字段 | 账号 test01 | 权限 |
| 示例：状态变为“已解决”后未通知负责人 | 项目 A | 解决通知规则 | 工作项 A-118 | 自动化 |
字段断点：先查数据是否迁到，再查配置是否重建
字段类断点的核心判断是：这个字段的问题出在“数据没迁过来”，还是“字段配置在新环境里没重建”。两者表现相似，处置方式完全不同，必须先区分再动手。
常见原因假设
可以按可能性列出几类假设：原插件引入的自定义字段未纳入迁移导出范围；字段迁到了但选项值映射丢失或截断；字段类型在新系统中不兼容，导致值无法落位；字段本身存在，但未加入对应工作项类型或项目的界面方案，用户看不到。ONES 的 Jira 迁移方案覆盖项目、工作项、状态、字段、流程、附件和历史记录，并迁移问题属性与属性值、字段配置等系统配置；对于原插件承载的定制字段，迁移前需要逐项评估，不能假设所有插件字段都能一一对应。
验证证据与判定标准
抽样比对是最直接的证据：在原 Jira 中导出若干工作项的字段值，与新系统中同一工作项逐项对照。判定标准可以这样设定——字段在新系统中不存在，属于配置未重建或未迁移；字段存在但值为空，需要进一步看原系统是否有值，原系统有值而新系统为空，倾向数据未迁到或映射失败；字段有值但选项集缺少部分选项，属于选项映射不完整；字段和值都在但用户看不到，属于界面方案或权限问题，转入下一节排查。
字段断点排查顺序
- 字段是否存在：在新系统对应工作项类型中确认字段是否已创建。
- 选项值是否完整：对照原系统选项集，逐项核对选项名称与数量。
- 字段是否在对应界面可见：检查字段是否加入该项目、该工作项类型的界面方案。
- 历史值是否保留：抽样比对历史工作项的字段值，确认迁移前后的对应关系。
| 核查项 | 验证方法 | 判定标准 |
|---|---|---|
| 字段是否存在 | 在工作项类型配置中查找字段 | 存在则进入下一项；不存在则记录为配置缺失 |
| 选项值是否完整 | 与原系统选项集逐项对照 | 名称与数量一致为完整；缺项记录缺失选项 |
| 界面是否可见 | 用普通成员账号打开工作项详情 | 能看到字段即界面配置到位；看不到则检查界面方案 |
| 历史值是否保留 | 抽样 10 至 20 条历史工作项比对 | 值与原系统一致为保留；为空或错位记录样本 |
权限断点：从角色映射查到字段级控制
权限断点最容易被误判为数据丢失：用户看不到某个字段或某条工作项，第一反应往往是“数据没迁过来”。实际排查应从项目可见性开始，逐层向下确认，而不是先去查数据。
常见原因假设
原插件可能引入了字段级权限控制，迁移后这类细粒度配置未必自动重建；项目角色与用户组的映射可能不完整，导致部分成员落在角色之外；用户组与角色的对应关系可能错位，例如原系统的“测试组”在新系统中被映射到了错误的角色。ONES 从 Jira 迁移时会迁移用户、用户组以及权限配置等系统配置，但原插件附加的字段级控制仍需按原逻辑逐项核对。
验证证据
用不同角色的账号复现同一操作，是最有效的验证方式：管理员账号能看到和编辑，普通成员看不到，说明问题在权限而非数据。再对比原系统中该角色的可见与可编辑范围，确认新系统是否收窄或放宽。记录每个角色的实际结果，形成角色对照记录。
权限断点排查顺序
- 项目可见性：确认用户能否进入该项目，不能进入则先查项目成员配置。
- 角色成员映射：核对该用户所属用户组与项目角色的对应关系是否与原系统一致。
- 字段级可见与编辑权限：确认该角色对目标字段是否具备查看和编辑权限。
- 工作流条件限制：检查状态流转是否设置了条件或校验，导致按钮不出现或操作被拦截。
| 角色 | 原系统可见范围 | 原系统可编辑范围 | 新系统实际结果 | 差异记录 |
|---|---|---|---|---|
| 项目管理员 | 全部字段 | 全部字段 | 一致 | 无 |
| 开发成员 | 除预算字段外全部可见 | 状态与工时 | 预算字段可见 | 字段级权限未重建 |
| 测试成员 | 严重程度可见可编辑 | 严重程度 | 不可见 | 角色映射待核对 |
自动化断点：核对触发事件、条件与执行身份
自动化不触发时，原因可能分布在规则的多个环节：规则本身没建、触发事件没命中、条件字段失效、执行身份权限不足、动作配置错误。逐项核对比整体重写更可靠。
常见原因假设
原插件中的自动化规则未迁移到新系统，需要重建；触发事件的名称或状态映射发生变化，例如原系统的“已解决”在新系统中对应不同状态；条件引用的字段已改名、改类型或被删除；执行身份（规则以谁的身份运行）缺少必要权限，导致动作被静默拦截。ONES 的流程自动化可承接常用插件场景，但具体规则的迁移能力边界需要按实际规则逐条确认。
验证证据
用测试工作项主动触发规则，查看执行日志中的触发记录、条件判断结果和动作执行结果。同时把原规则与新规则并排比对：触发事件是否一致、条件字段是否指向有效字段、执行身份是否具备动作所需权限。日志中没有触发记录，说明触发事件未命中；有触发记录但条件未通过，说明条件配置有偏差；条件通过但动作失败，重点查执行身份权限。
自动化排查顺序
- 规则是否存在：确认原规则在新系统中已建立对应规则。
- 触发事件是否命中：用测试工作项制造触发条件，查看日志是否记录触发。
- 条件字段是否有效：核对条件引用的字段是否存在、类型是否匹配、值是否可达。
- 执行身份是否有权限：确认规则运行身份对目标工作项和字段具备操作权限。
- 动作结果是否符合预期：检查动作执行后的实际结果与配置目标是否一致。
| 原规则 | 新规则 | 触发事件 | 条件 | 执行身份 | 结果 |
|---|---|---|---|---|---|
| 状态变为已解决时通知负责人 | 已重建 | 一致 | 一致 | 原为插件服务账号，新为管理员 | 通知成功 |
| 优先级为高时自动指派组长 | 已重建 | 一致 | 优先级字段已改名 | 一致 | 未触发，条件失效 |
| 逾期 3 天自动提醒 | 未建立 | — | — | — | 规则缺失 |
处置与验证：修复后如何确认恢复并防止复发
原因确认后，修复动作本身也有顺序和风险边界。建议先补数据、再调权限、最后改自动化：数据是权限判断和自动化条件的基础，顺序颠倒会导致重复排查。批量修改字段值、批量调整角色或批量启用规则前，先备份相关配置或留存快照，并选择低峰时段执行，出现异常时能回退到修改前状态。
验证方式
用最初记录的复现样本逐一回归，确认每个样本的实际结果与期望一致；对历史数据做抽样检查，确认修复没有影响其他工作项；对自动化规则观察一段时间的执行日志，确认触发与动作稳定。验证记录应包含样本编号、修复动作、回归结果和验证人，便于后续追溯。
复发预防
建立迁移后的字段与规则对照清单，记录每个原插件字段、权限配置和自动化规则在新系统中的对应关系与状态；在后续插件变更、字段调整或规则修改时同步更新清单。这样下一次出现断点时，可以直接从清单定位是迁移遗留还是后续变更引入，缩短排查路径。
| 预防项 | 具体做法 | 更新时机 |
|---|---|---|
| 字段对照清单 | 记录原字段名、新字段名、类型、选项集、所在界面方案 | 字段新增或调整时 |
| 权限对照记录 | 记录角色、用户组、字段级权限范围 | 角色或成员变动时 |
| 自动化规则清单 | 记录规则名称、触发事件、条件、执行身份、负责人 | 规则新建或修改时 |
| 回归样本库 | 保留代表性工作项作为固定验证样本 | 每次迁移或大版本调整后 |
常见问题
原插件字段在新系统中找不到，能直接判定为数据没有迁移吗？
不能直接判定。字段找不到有两种常见情形：字段本身未创建，属于配置未重建；字段已创建但未加入对应工作项类型或项目的界面方案，用户看不到。先在工作项类型配置中确认字段是否存在，存在再检查界面方案，最后才抽样比对历史值判断数据是否迁到。ONES 的 Jira 迁移方案覆盖字段配置与问题属性值，原插件承载的定制字段需要在迁移前逐项评估对应关系。
权限问题排查到一半，发现部分字段确实没有值，应该先处理哪一边？
先处理数据，再处理权限。权限判断和自动化条件都依赖字段是否存在、字段值是否有效，如果字段值本身缺失，权限调整后用户仍然看不到有效内容，容易造成重复排查。建议先完成字段断点的核查与补数，再回到权限路径继续核对角色映射与字段级权限。
自动化规则在测试环境正常，上线后不触发，重点查什么？
重点查三处差异：触发事件在生产数据中是否真实发生，例如状态名称或流转路径与测试环境不同；条件引用的字段在生产项目中是否存在且类型一致；执行身份在生产环境中是否具备目标工作项和字段的操作权限。查看生产环境的规则执行日志，确认是未触发、条件未通过还是动作被拦截，再针对性修复。
批量修复字段值或角色权限时，有哪些风险需要提前控制？
批量修改会同时影响多个项目和工作项，出错后回退成本高。执行前备份相关配置或留存快照，选择低峰时段操作，并先用少量样本验证修改逻辑。修改后立即用原复现样本回归，再抽样检查历史数据，确认没有影响其他工作项。角色权限调整还应记录调整前后的对照关系，便于追溯。
迁移完成后，怎样减少后续插件变更再次引发断点？
建立并维护三份对照清单：字段对照清单记录原字段名、新字段名、类型、选项集与所在界面方案；权限对照记录记录角色、用户组与字段级权限范围；自动化规则清单记录规则名称、触发事件、条件、执行身份与负责人。在字段新增、角色变动或规则修改时同步更新，下次出现断点时可直接从清单判断是迁移遗留还是后续变更引入。
