StatusPath Reports使用指南
Jira 状态重命名和本地化后如何核对工作流报表
Jira 状态被重命名或翻译后，核对报表时应把 ID（而不是可见标签）作为状态身份。重命名会改变状态对象的当前名称；翻译会改变按用户语言返回或渲染的标签；删除后重建或替换状态则会产生新的身份。StatusPath 可以为不同的同名状态分别计算列，但当前表格和导出表头会重复可见标签，并不会显示 Jira 状态 ID。不能把表头文字本身当作审计身份依据。
区分状态身份和显示标签
状态标签回答“现在显示什么文字”，状态 ID 回答“哪个 Jira 状态对象产生了这项指标”。状态重命名、Jira 按语言显示翻译，或两个状态对象使用相同当前名称时，这两个问题就会分开。
Atlassian 说明，重命名状态会更新所有使用该共享状态的工作流和空间。Jira 也支持工作流状态翻译，缺少对应翻译时会使用默认值。Atlassian 的本地化状态 REST 示例表明，同一个稳定 id 可以具有随用户语言变化的 name，并同时返回 untranslatedName。因此，可见标签不能作为跨项目的稳定关联键。
| 变更 | 状态 ID | 可能变化的内容 | 报表处理 |
|---|---|---|---|
| 重命名 | 相同 | 当前默认名称 | 保留指标身份，更新记录标签 |
| 翻译 | 相同 | 用户语言下的 name |
保留指标身份，记录审核语言 |
| 删除后重建或替换 | 不同 | 身份和历史映射 | 视为新状态，并核对两个 ID |
修改报表前，先使用以下判断表：
| 证据 | 含义 | 报表处理 |
|---|---|---|
| 状态 ID 相同，当前标签改变 | 同一个 Jira 状态对象有了新的显示名称 | 保留一个指标身份，并更新记录中的标签 |
| 状态 ID 相同，不同语言查看者看到不同标签 | 同一个状态按语言显示不同文字 | 保留一个指标身份，并记录审核时使用的语言 |
| 状态 ID 不同，当前标签相同 | 两个不同 Jira 状态对象看起来相同 | 保留两项指标，并保留 ID 到工作流的映射 |
| 预期状态 ID 没有计算值 | 可能是范围、历史或列发现问题 | 使用状态列缺失排查指南 |
Atlassian 的工作流状态 REST 文档使用 id 和 name 共同描述状态。文档还特别提醒：一个名称可能被多个状态使用，需要精确结果时应优先使用 ID。
真实 Jira 场景：两个不同状态现在都叫 Review
假设一份跨项目 Time in Status 报表包含两个工作项。Platform 工作流的状态 ID 为 10012，记录的转换区间中标签是 Peer Review，当前状态目录中的名称则是 Review。Storefront 工作流使用另一个独立状态，ID 为 10013，当前名称也为 Review。
固定报表配置如下：
| 设置 | 值 |
|---|---|
| Source | key in (PLAT-1, SHOP-1) ORDER BY key ASC |
| Report | Time in Status |
| Calendar | All time (UTC) |
| Format | Decimal Hours |
| History | 完整历史 |
| 状态选择 | ID 10012 和 10013 |
相关 Jira 证据为：
| 工作项 | 项目 | 区间中的状态 ID | 区间记录的标签 | 当前目录标签 | UTC 区间 |
|---|---|---|---|---|---|
PLAT-1 |
Platform | 10012 |
Peer Review | Review | 7 月 22 日 09:00–11:00 |
SHOP-1 |
Storefront | 10013 |
Review | Review | 7 月 22 日 10:00–14:00 |
Jira 工作项的 Activity → History 会记录字段编辑和工作流移动。应检查实际 changelog 记录，以及集成能够取得的状态 ID；不要假设每一种 Jira 历史界面都会始终以相同形式保留旧标签。
可见标签随语言变化，而计算时长保持不变。这两张截图不能证明 StatusPath 会显示底层 ID：当前版本不会在冲突表头中追加 ID，CSV/XLSX 导出也可能包含重复状态标签。如果结果需要脱离报表单独作为审计证据，应在 Jira 中使用不同的状态名称，或随导出文件保存经过审核的 ID 到列映射。
人工验算两个状态列
使用 All time (UTC) 时，每个时长都是直接相减：
PLAT-1，状态 10012 = 2026-07-22 11:00Z - 2026-07-22 09:00Z
= 2 小时
SHOP-1，状态 10013 = 2026-07-22 14:00Z - 2026-07-22 10:00Z
= 4 小时
预期指标矩阵如下：
| 工作项 | 状态 10012（可见标签：Review） |
状态 10013（可见标签：Review） |
行总计 |
|---|---|---|---|
PLAT-1 |
2.00 |
- |
2.00 |
SHOP-1 |
- |
4.00 |
4.00 |
| 列总计 | 2.00 | 4.00 | 6.00 |
横线表示该工作项在这个独立状态 ID 下没有可计算区间，不表示一次零时长停留。人工验算中的 6.00h 小计只是交叉检查（2.00h + 4.00h），报表不会按名称自动合并两个 ID 列；只有明确建立并审核报表状态组时才应组合。Time in Status 区间计算指南说明了进入时间、离开时间、Calendar 和历史窗口规则。
逐步核对重命名或本地化状态
1. 按 ID 获取当前状态目录
在本例中，英文账户与中文账户可以为同一个 ID 得到不同的 name：
英文 /rest/api/3/status → {"id":"10012","name":"Review","untranslatedName":"Review"}
中文 /rest/api/3/status → {"id":"10012","name":"评审","untranslatedName":"Review"}
应使用已认证的 Jira 站点响应，并同时记录工作流或项目上下文。Atlassian 说明 REST 结果会反映请求账户的语言。状态查询还受 Jira 权限和工作流使用情况影响；工作流状态 API 对相关操作记录了 Browse projects 权限与活动工作流限制。重名正是待排查问题时，不要使用只含名称的查询：Atlassian 提醒这可能只解析第一个匹配，而 ID 是精确键。
2. 证明转换证据
打开每个代表性工作项的 Activity → History，记录转换时间戳、可以取得的状态 ID、显示标签和查看者语言。先用不依赖状态名称的 JQL 固定工作项范围：
key in (PLAT-1, SHOP-1)
ORDER BY key ASC
Atlassian 当前的 JQL 字段参考与 JQL 运算符参考对历史状态 ID 匹配的说明并不一致。因此本例只用 key 固定工作项范围，用 REST/changelog ID 核对身份；JQL 不计算时长。
3. 固定计算输入
保持 JQL 范围、Calendar、Format、工作项日期范围、Trim History 边界和报表时间不变，并同时选择两个状态身份。只对比名称，无法区分标签变化与数据范围或计算变化。
4. 先核对 ID，再核对标签
先把每个指标列映射到 Jira 状态 ID，再显示或记录当前标签。审核本地化结果时，还应记录每张截图或审批所用的 Jira 语言。不要通过手工替换指标列来“翻译”ID 到状态的映射。
5. 保存可审核的映射
在 Saved Report 旁保留简短清单：
| 状态 ID | 英文标签 | 中文标签 | 相关项目或工作流 |
|---|---|---|---|
10012 |
Review | 评审 | Platform |
10013 |
Review | 评审 | Storefront |
StatusPath 表格视图文档说明了动态指标列、可见性、筛选，以及缺失值和显示零值之间的差异。当同名表头可能产生歧义时，应把这份映射与已审核配置一起保存。由于当前表格与导出都不显示 ID，不能把列顺序或重复表头当作可独立使用的长期证据。
常见错误
按可见表头合并列
两个名为 Review 的列可能属于不同状态 ID。只有当报表问题明确要求跨工作流状态组，并且审核者批准映射时，才应组合它们。
假设当前表头或导出能够标识状态 ID
不能。当前表格和导出遇到同名状态时可能出现重复表头。应使用 Jira 状态目录和经过审核的映射；如果导出文件必须能够独立识别，应先让 Jira 状态名称保持不同。
把翻译当成新的工作流步骤
本地化标签可能只是同一个状态身份的另一种显示文字。添加另一项指标或认定 Jira 又记录了一次转换前，应先检查 ID。
使用只包含名称的 REST 查询
名称重复时，ID 才是精确键。Atlassian 提醒，按名称查询可能只返回第一个匹配状态。
假设旧标签始终可见
本例中受控的 PLAT-1 changelog 区间包含 Peer Review，但这不能证明 Jira 在所有情况下都遵循同一种存储或显示规则。应检查本站点的实际 History 或 changelog 响应，并保留观察到的证据。
期待 JQL 计算时长
JQL 可以固定候选工作项，但在本次核对中不是状态身份依据。Time in Status 还需要经过验证的状态 ID、进入和离开时间、历史边界与 Calendar。
把同名列误判为缺失列
如果两个底层 ID 和数值都存在，问题是标签歧义，而不是列发现。如果某个预期 ID 完全没有对应列，再按照独立的缺失列流程排查。
常见问题
重命名 Jira 状态会创建新的状态 ID 吗？
不要根据新标签推断身份。应在变更前后获取 ID：ID 相同表示现有状态对象换了名称；ID 不同则表示正在比较不同状态。
两个 Review 列一定是重复列吗？
不一定。本例中的 ID 10012 和 10013 彼此独立。决定两个指标是否回答同一个业务问题前，应核对 ID、工作流和代表性历史。
StatusPath 会在同名状态列表头中显示 Jira 状态 ID 吗？
当前版本不会。计算可以保持分开，但重复可见标签仍有歧义。当输出必须自带身份信息时，应保存外部映射或使用不同的 Jira 状态名称。
本地化会改变计算时长吗？
仅翻译标签不会改变转换发生的时间。时长变化应从工作项范围、进入或离开时间戳、Calendar、历史边界或报表时间中排查，不能在没有证据时归因于翻译文字。
JQL 能区分同名状态吗？
同名状态核对不能只依赖 JQL。Atlassian 当前的字段与运算符参考对历史 ID 匹配的说明并不一致，因此应用 JQL 固定工作项范围，再用 REST 或 changelog ID 与工作流上下文核对身份；实际时长仍需另外计算。
如果 Jira History 没有显示旧名称怎么办？
不要凭记忆重建。记录当前 ID 和标签，检查可以取得的 changelog 证据；审计确实需要旧标签时，再使用经过批准的工作流变更记录。
相关指南
- 为什么 Time in Status 报表缺少某个 Jira 状态列
- 如何计算 Jira Cloud 中的状态停留时间
- 如何使用 JQL 创建 Jira Time in Status 报表
- 如何审核 Jira 工作项活动报表
把身份依据和可见标签保存在一起
使用 StatusPath Reports，在你的 Jira 权限范围内复现双 ID 核对，并把状态映射与审核后的报表一起保存。根据表格视图文档设置可见列；准备好用自己的 Jira History 验证重命名或本地化状态时，可在 Atlassian Marketplace 试用 StatusPath Reports。