如何用 JQL 列出上月离开“To Do”的 Jira 工作项
使用 4 条可复制 JQL 查找上月更新且当前已离开 To Do，或在上月发生状态变更的 Jira 工作项，并用 StatusPath 分析状态时长、计算进入边界、次数与流转。
需要的是月度 Kanban 清单，而不是另一张累计图？先使用 Jira 原生 JQL。如果清单和当前 Status 列已经能回答问题，就不需要安装报表应用。只有还要分析状态时长、最早计算进入边界、重复状态区间、定向流转次数，或导出已核对的 CSV/XLSX 时，再使用 StatusPath。
披露： StatusPath Reports 由本指南发布者 BlueGrove Labs 开发。
本指南来自一个真实 Jira Cloud 需求。一位管理员在 Atlassian Community 的月度 Kanban 报表问题中，希望列出上月更新过、当前已超过 To Do 的工作项及其状态。已采纳的讨论还给出了 WAS ... DURING 和 CHANGED ... DURING，提问者确认这些答案有帮助。下面第一条查询匹配“当前状态类别 + 上月更新时间”范围，另外 3 条回答更窄的历史问题：哪些工作项在上月实际发生过状态变更。Atlassian 的 JQL 运算符参考记录了 CHANGED 支持 DURING、FROM 和 TO；JQL 函数参考记录了相对的 startOfMonth 与 endOfMonth。
4 条可以直接复制的 JQL
请把状态名称替换为当前 Jira 工作流中的准确名称。如需限定单个项目，可在查询开头加入 project = YOURKEY AND。
上月更新且当前已超过 To Do 的工作项
statusCategory != "To Do"
AND updated >= startOfMonth("-1")
AND updated <= endOfMonth("-1")
ORDER BY updated DESC这条查询直接对应原始 Community 需求。statusCategory 按现在的值判断，updated 选择上个自然月；它不是月末状态快照，当前已经回到 To Do 的工作项不会匹配。
上月发生过任意状态变化
status CHANGED DURING (startOfMonth("-1"), endOfMonth("-1"))
ORDER BY updated DESC只要上个自然月发生过工作流移动就应进入清单时，使用这条查询。
上月离开 To Do 的工作项
status CHANGED FROM "To Do"
DURING (startOfMonth("-1"), endOfMonth("-1"))
ORDER BY key ASC它会包含当月发生过离开 To Do 流转的所有工作项，即使该工作项后来又回到 To Do。
上月从 To Do 进入 In Progress 的工作项
status CHANGED FROM "To Do" TO "In Progress"
DURING (startOfMonth("-1"), endOfMonth("-1"))
ORDER BY key ASC当报表范围由一个明确的 FROM → TO 流转定义时，使用精确状态对。
什么时候 Jira 原生功能已经足够
在 Jira 高级工作项搜索中运行查询，加入 Key、Summary、Status、Assignee 及复盘需要的业务字段。确认数量，抽查一个应包含的工作项，需要重复使用时保存为 Jira Filter。
Status 列显示的是工作项现在的状态，不是上月最后一天的历史状态。如果成员范围和当前状态已经解决问题，就停在这里。
以下 5 个虚构工作项说明匹配事件与当前值为什么必须分开：
| 工作项 | 上月记录的事件 | 当前 Status | 这一行能证明什么 |
|---|---|---|---|
KAN-101 | To Do → In Progress | Done | 上月离开过 To Do。 |
KAN-102 | To Do → In Progress | In Review | 当前状态可以晚于匹配事件。 |
KAN-103 | To Do → Blocked | To Do | 后来返回 To Do 不会抹掉先前离开事件。 |
KAN-104 | To Do → In Progress | In Progress | 当前状态恰好与事件目标相同。 |
KAN-105 | To Do → Cancelled | Cancelled | “离开 To Do”比“开始交付”更宽。 |
这些是合成键，不是客户案例或真实 Jira 站点结果。
StatusPath 能增加什么
在 StatusPath Reports 中把已验证查询用作 JQL 数据源。JQL 仍然只决定哪些工作项进入报表，不负责计算工作流时长；需要时保留 Jira 当前 Status 字段。
根据下一问选择报表：
- Time in Status：所选工作项在各状态中、跨匹配重复区间的累计计算时长。
- Status Entry Date：当前计算历史窗口内，各状态最早的计算区间起点。使用完整历史时，它表示最早的计算进入；启用 Trim History 后，如果某状态区间在窗口开始前已打开，显示值可能是 Trim From 边界。它不是最近一次进入或全部进入记录。
- Status Count：计算出的状态区间或进入次数。跨过 Trim From 的 carry-in 区间可能在边界计 1 次，因此裁剪后的 Status Count 不一定等于当月实际发生的 transition 事件数。
- Transition Count：计算窗口内记录的、匹配定向“来源状态 → 目标状态”的流转次数。
当前指标定义见报表类型，Status Entry Date 边界见如何查找 Jira 工作项进入状态的日期。
对齐工作项总体与历史窗口
如果指标只应覆盖上月，请把 Trim History 设置为该月固定的第一天与最后一天。Date To 会包含所保留 Work Calendar 时区中的完整所选日期，并受报表生成时间上限约束。Jira 搜索用户的时区与 StatusPath 保留的 Work Calendar 时区应分别记录；StatusPath Calendar 不会改变 Jira JQL 语义。
Count 和 Entry Date 不是时长报表，因此界面会隐藏 Calendar 控件，但保留的所选 Work Calendar 时区仍定义 Trim History 日期。依赖同一组月度边界前，应先在时长报表中确认并记录 Calendar。Jira 报表日期范围如何裁剪状态历史解释了总体、计算窗口、完整 Date To 和时区边界。
抽查代表行后，可以保存可复用配置，并在需要时间点文件时导出结果。Saved Reports保存配置并重新读取当前 Jira 数据，不会冻结上月工作项；将 Jira Time in Status 导出到 Excel生成的是一次性已审核 CSV/XLSX，不是自动更新快照。
生成报表前必须确认的边界
- JQL 负责选择工作项范围，不负责计算两次状态变化之间的时长。
status CHANGED TO "In Review" DURING (...)会漏掉月初前已进入 In Review、但整月仍停留其中的工作项。计算重叠时长时，应使用更宽的总体，再用 Trim History 裁剪历史。- 相对月份函数会随重新运行而移动；需要复现历史结果时应记录生成时间并使用固定日期。
- 当前 Status 不是月末快照。
- StatusPath Saved Reports 不是不可变快照或自动定时月报。
- StatusPath 不是所有字段的完整审计日志，也不承诺逐事件 actor 报表。
清单之外还需要工作流证据？
如果 Jira 原生查询已经解决问题，请继续使用原生方案。如果还要衡量所选工作项的状态时长、计算进入边界、重复状态区间或匹配的定向流转次数，并导出已审核结果，可以在 Atlassian Marketplace 查看 BlueGrove Labs 开发的 StatusPath Reports，再判断它是否适合这次复盘。