How can I edit issues of a project in bulk using python and jira rest api 3

[Fitehalew Demilew]

How can I perform bulk editing of issues in a specific project using Python and JIRA REST API 3? I need to edit issues with a status of 'Reopened' or 'In Progress' and add labels to each issue. With potentially thousands of issues in the project, what is the most efficient approach to achieve this?

[David Bakkers · Accepted solution]

Hello @Fitehalew Demilew 

There are no REST API endpoints for bulk editing (updating) issues (refer to JRACLOUD-70356), you have to edit them one at a time.

Just loop / iterate through the list of issues, in batches.

[Fitehalew Demilew]

Is it efficient to use a loop for performing edits on hundreds of issues per day in the JIRA Service Desk?

[David Bakkers]

Efficient compared to what? Not doing it? Doing via the GUI?

What's the criteria for it being inefficient? Taking 1 minute? Taking 1 hour?

[Fitehalew Demilew]

I am wondering if it is efficient to edit hundreds of issues one by one by sending an edit request. Is there any other way to do this or this is only way we have?

[David Bakkers]

Sorry, I just don't understand what you mean by 'another way'. The way to do it is the way I have described.

It's now up to you to write the Python code to achieve the outcome and then decide for yourself whether or not that meets your criteria of being 'efficient'.

Have fun.

PS. If you think my original answer was correct, please mark it as such. Thanks.

[Fitehalew Demilew]

Okay, thank you

[Carsten Stepan]

@David Bakkers  I have the exact same requirement, and efficency for me means doing this in a single request instead of firing hundreds of requests, because doing the latter will sooner or later run into an HTTP429 "Too many requests"-error, depending oin the request-limit (no idea how one may set this, though). Of course one may just sit and wait until the frame-limit disappears, send another hundred of requests and eventually get the same again. However this is really annoying.

[David Bakkers]

@Carsten Stepan 

You have no choice, you cannot do it a single request, no matter how much you want it to be so or how 'annoying' this is.

When submitting your requests, you must write your code properly to listen to the responses from the REST API and if you start getting the 429 limit warnings, then BACK OFF, just as it says in the Rate limiting documentation.

The topic of how to submit requests in batches and to add jitter / delay to big API requests to stay within rate limits is extensively documented elsewhere.

[Carsten Stepan]

Of course I can scatter my requests so they don't touch the 429-boundary, e.g. by jitting, delaying and whatsoever. However that won't reduce the number of requests being sent at all (or even increases the number). This is like going to your bank and ask for a diposit of 50k in tranches of 10€ per request. So in fact the person at the waiter just sits there and waits for your 5000 requests, instead of handling a single one.

I agree this is a hard design-issue and involves many factors like load-balancing and whatever. But relying on the client to do all the heavy partioning is a bad deal, either.

I see it's not possible and I am fine with that. That was just my statement.

[David Bakkers]

You can rant and rave about how much you don't like the scope of the REST API's functionality or Atlassian's Acceptable Usage Policies as much as you like... but that won't change a thing.

I regularly do changes to very, VERY big datasets in Jira Cloud environments. All I do is split my requests into batches with randomised small delays between each, and I NEVER run into 429s any more. Writing code that works within the environment's boundaries is a lesson that good developers should learn early.

In the meanwhile, vote for JRACLOUD-70356 .

[David Bakkers]

@Fitehalew Demilewand @Carsten Stepan I completely forgot about something until early today... Atlassian recently conducted an RFC for considering bulk Issue edit and move endpoints for the REST API in preparation for trialling them via a Partner Early Access Program (EAP). For more information, read this recent post in the Dev's forum.

I'm not a Partner, so can't participate in the EAP, but I expect the first trial of those new endpoints will happen later in the year, so the functionality you're looking for might not be that far away :)