What is the database table name, which stores Issue Transition information?

[Pranita Warik]

I want to fetch the Issue Transition Date (as highlighted in the screenshot) on each status transition happening in the Issue.

[Mehmet A _Bloompeak_]

Hi @Pranita Warik ,

Apart from changegroupitem DB table, you can get the data using below rest api.

https://docs.atlassian.com/software/jira/docs/api/REST/8.15.0/#api/2/issue-getIssue

Or you can search for a marketplace apps which extract the data for you. One of them is Status Time app developed by our team. It provides reports on how much time passed in each status as well as status entry dates and status transition count. Report can be exported as CSV, so that you can use external tools like Microsoft Excel or Google Spreadsheet to process the exported data.

Once you enter your working calendar into the app, it takes your working schedule into account too. That is, "In Progress" time of an issue opened on Friday at 5 PM and closed on Monday at 9 AM, will be a few hours rather than 3 days. It has various other reports like assignee time, status entry dates, average/sum reports(eg. average in progress time per project).

Here is the online demo link, you can see it in action and try.

If you are looking for a free solution, you can try the limited version Status Time Free. Hope it helps.

[Emre Toptancı _OBSS_]

Hello Radek,

For on-prem Jira editions, the DB table that holds this data is changegroupitem. All issue changes are in this db table so you will need to filter by issueID and status field.

Getting flexible reports from this table is pretty tiresome. For a ready built solution that offers great flexibility and details, our team at OBSS built Timepiece - Time in Status for Jira app for this exact need. It is available for Jira Server, Cloud and Data Center.

Time in Status allows you to see how much time each issue spent on each status or assigned to each assignee. You can also combine statuses into consolidated columns to see metrics like Ticket Age, Cycle Time or Lead Time. You can also use one of the 4 date reports to see issue transition dates. (4 reports to see first/last transition date to/from a status)

You can calculate averages and sums of those durations grouped by issue fields you select. (For example see the total InProgress time per Epic, or average Resolution Time per issuetype). 

   

The app calculates its reports using already existing Jira issue histories so when you install the app, you don't need to add anything to your issue workflows and you can get reports on your past issues as well.

The app has Custom calendar support that your are looking for. This feature enables you to get your reports based on a 24/7 calendar or your custom business calendar. (This one is important because a 24/7 calendar in most cases shows misleading data. For example an issue created at 16:00 on Friday and was resolved at 09:00 on next Monday seems to stay open for 2,5 days but in terms of business hours, it is only a few hours. You can see this using Time in Status by OBSS.)

Finally, the app has History Trim feature. This feature allows you to report on a subsection of issue histories instead of the whole history. Very useful when you want to focus on changes made during sprint or project phase.

Using Time in Status you can:

• See how much time each issue spent on each status, assignee, user group and also see dates of status transitions.
• Calculate averages and sums of those durations grouped by issue fields you select. (For example see average InProgress time per project and per issuetype.)
• Export your data as XLS, XLSX or CSV.
• Access data via REST API. (for integrations)
• Visualize data with various chart types.
• See Time in Status reports on Jira Dashboard gadgets (released for cloud, server&DC gadget coming soon)

Timepiece - Time in Status for Jira

EmreT

[Radek Dostál]

These are fetched from the issue history (changeitem in db I think, something with "change" in it), there is no specific table regarding transitions as far as I know, even the plugin itself 99% in my view goes by issue history.

Question is, why do you want to get this from the database specifically? That is one of the most painful, inconvenient ways to get such data.