I’m working with the Python JIRA library and need to pull all the change history for a specific ticket. Right now I’m using this approach:
ticket_results = jira_client.search_issues(my_query, expand='changelog')
The problem I’m running into is that when a ticket has more than 100 changelog entries, I only get the first 100 back. The response shows there are more entries available but they get cut off at 100.
I need to figure out how to paginate through the remaining changelog entries. Is there a way to set a startAt parameter and make additional calls to get the next batch of changelog data?
I know that JIRA’s REST API v3 has a dedicated changelog endpoint that might help with this, but I’m not sure if the Python library supports it directly. I’d prefer to stick with the library instead of making raw HTTP requests if possible.
Has anyone dealt with this pagination issue before? What’s the best way to retrieve the complete changelog history for tickets with lots of changes?
Had the same issue a few months back with legacy tickets that had hundreds of changelog entries. I used the issue() method with the expand parameter and checked the changelog’s maxResults and total properties. You can call jira_client.issue(ticket_key, expand=‘changelog’, fields=‘’) multiple times with different startAt values. Check the changelog object in the response - it has the pagination metadata. issue.changelog.maxResults gives you page size, issue.changelog.total shows total entries. Keep incrementing startAt until you’ve got everything. It’s manual but works within the library instead of dropping to raw HTTP calls.
The Python JIRA library doesn’t paginate changelog automatically - super annoying. I got around this by hitting the raw REST API with different startAt values. Use the library’s _get_json method to call /rest/api/2/issue/{key}/changelog directly with pagination params. Try jira_client._get_json(f’issue/{ticket_key}/changelog?startAt={offset}&maxResults=100’). Loop through these calls, bump startAt by 100 each time until you’ve grabbed everything. Not pretty, but it works without ditching the library entirely. Watch your rate limits if you’re processing tons of tickets.
yeah, the jira library’s a pain for this. i used the changelog’s startAt property in a while loop. after your initial search_issues call, check if len(ticket.changelog.histories) < ticket.changelog.total. if it is, keep calling jira_client.issue() with expand=‘changelog’ and bump startAt by 100 until you get everything. it’s hacky but works within the library.