Hey folks, I’m working with the JIRA 6 REST API and I’m stuck. I can pull lots of data that matches our web cloud UI, but I can’t figure out how to get the transition history for issues.
I want to see all the transitions an issue has gone through, like when it moved to code review, QA, or got closed. It would be great if I could also see who made each transition.
I’ve tried using the /issue/{issueIdOrKey}/transitions endpoint, but it only shows the current possible transitions, not the history. I also tried expand=changelog, but the data doesn’t match up with the transitions I see in the web UI.
Has anyone managed to get this working? Any tips or tricks would be super helpful. Thanks!
hey emcarter, i ran into dis same issue. the /issue/{issueIdOrKey}/changelog endpoint is wat ur lookin for. it gives u all the history, including status changes n who made em. jus make sure u got the right permissions. if u need more help, lemme kno!
For retrieving transition history in JIRA 6 REST API, you’ll want to use the /issue/{issueIdOrKey}/changelog endpoint as mentioned. However, to get comprehensive data, you might need to implement pagination. The API typically limits results, so you’ll need to make multiple requests to fetch the entire history.
Consider using the ‘fields’ parameter to narrow down the data returned, focusing on status changes. This can improve performance for large issues with extensive histories. Also, ensure your authentication token has sufficient permissions to access this data.
If you’re still encountering discrepancies between the API results and the web UI, it might be worth checking if there are any custom fields or workflow steps in your JIRA instance that could be affecting the data representation.
I’ve been down this road before, and it can be tricky. The /issue/{issueIdOrKey}/changelog endpoint is indeed the way to go, but there’s a catch. You need to parse the changelog entries carefully to extract the transition history.
In my experience, look for ‘status’ field changes in the changelog. Each status change represents a transition. You’ll get the ‘from’ and ‘to’ states, timestamp, and the user who made the change.
One gotcha: if you have custom workflows, some transitions might not change the status field. In that case, you might need to look for changes in other fields that indicate a transition in your specific setup.
Also, don’t forget about performance. If you’re dealing with long-lived issues, the changelog can be massive. Consider implementing some caching mechanism on your end to avoid hammering the API for every request.