To help you better understand where JQL works best for historical reporting, we’ve compiled the following table, showing which field types are compatible with historical operators.
| Field Type |
Supports Historical Operators (WAS, WAS IN, WAS NOT, WAS NOT IN, CHANGED) |
Example queries with historical operators and notes |
|---|---|---|
| Status | Yes with all operators |
|
| Priority | Yes with all operators |
|
| Assignee | Yes, but only with WAS, WAS NOT, CHANGED |
|
| Reporter | Yes, but only with WAS, WAS NOT, CHANGED* |
|
| Resolution | Yes with all operators |
|
| Fix Version | Yes with all operators |
|
| Custom Fields (Date/Time) | Depends on configuration** | Jira doesn’t automatically track changes to Custom Fields in the audit log or issue history unless specific configurations are made. |
| Custom Fields (Text) | No | Only current value is stored for Text fields. ** |
| Attachment | No | While you can see the list of attachments on an issue, Jira does not maintain a history of when attachments were added or removed. |
| Component | No | This field is a static field that is set on the issue level and does not track changes over time. |
| Comment | No | The comments are stored with the issue but not in a way that allows historical querying of who commented or when a comment was added. |
| Due Date | No | It is treated as a one-time value on the issue that can be changed as needed, and Jira does not retain this historical change data |
| Epic Link | No | When you change the Epic Link field, Jira does not track the historical changes to which epic an issue was linked. Once the value is updated, Jira only keeps the current association. |
| Linked Issue | No | Jira stores only the current state of the link field. |
| Issue Type | No | The Issue Type is set when the issue is created and is rarely changed afterward (and even if it is changed, this change does not get recorded historically. |
| Labels | No | When labels are changed, Jira updates the field with the new set of labels but does not keep a historical record of previous labels. |
| Parent (Sub-task) | No | This is a single-value field, and once the parent is changed, the old parent relationship is not preserved. |
| Project | No | Changing the project of an issue is a relatively rare action, and Jira does not maintain a history of project changes. |
| Sprint | No | Once an issue is moved between sprints, Jira does not store the previous sprint assignments. |
| Time Tracking (Original Estimate, Time Spent) | No | Time Tracking fields are continuously updated when work is logged or estimates are adjusted. Jira does not maintain historical records of how much time was logged at specific points in time. |
| Worklog data | No | Data such as worklog author, worklog date, etc) is stored in Jira’s worklog entries, but worklogs themselves are not quarriable historically in the same way as other fields. |