My question is in the context of post-migration activities (from Server to Cloud) where bulk edits are required to data in migrated custom fields.
Other users might want to do bulk edits for other reasons.
In this case we need to update 5k to 6k issues.
I know it is possible to do this using bulk edit - you just need to repeat the process (6 times in my case) updating 1000 issues each run. This is pretty tedious, and more so for larger numbers of issues.
Instead I created a scheduled automation rule to update issues matching a specific JQL. This gets throttled and results in errors on the Automation page, but at least it does update the issues. Not sure how the Cloud Ops team feel about this...
Can you make a JQL query that returns a maximum number of rows? Something like SQL TOP or LIMIT clauses.
After reading the documentation I have not found a way to do this.
I guess you could do this using the REST API but that seems overkill for a simple search and replace operation.
Has anyone found a better solution?
Hi Dwight,
If there is something unique about the issues, then you can limit your query that way - such as are all of them or on the same project or multiple projects? Perhaps run the query to see how many your return using the create date, etc.
Yes, and...to John's answer:
How frequently are you running that scheduled trigger rule? I ask because that trigger (with JQL) is limited to 100 issues at a time (subject to what else happens in your rule with related issues). If you watch your processing time you may be able to tune the schedule to process 100 issues every X-minutes such that you do not exceed your service limits. Please look here for more information: https://support.atlassian.com/cloud-automation/docs/automation-service-limits/
Kind regards,
Bill
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboy- initially my automation rule frequency was hourly - meaning the issues would update in a few hours (6-7 hours). I increased the interval to 2 hours given how long the first run took. Rather slow, but it did update the issues with less tedium.
Regardless of the frequency/interval the automation rule still gets throttled (at about 1000 issues per-run). Will need to do this for our actual (production) Cloud migration, so I was hoping there was an easy way to improve the process.
If I could create an automation rule that processes only 100 issues per 'run' it would avoid these alerts, and I could use a higher frequency.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Thanks for that information, Dwight.
It appears something has changed as I thought the scheduled trigger was already limited to 100 issues at a time...and that throttling only happened when either the rule ran too frequently or it referenced to many related issues, per each triggered issue.
John's approach sounds like a good alternative, such as checking create date and make your own algorithm to limit processing. (For example, use the hour from {{now}} as a proxy for the number of days/months/etc. in the past to check in the JQL.) That would break up processing into 24 chunks.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Bill Sheboy - thanks for your suggestion of using {{now}} in a JQL query to limit the number of issues. That would help in our situation.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Subsequently found two JAC tickets that seem related. Although it doesn't look like there are any suggestions directly relating to enhancing automation. I'll send a request.
JRACLOUD-42307 Automatically Edit 1000 Issues Continuously if Issues to be Edited is more than 1000
JRACLOUD-68133 Cannot use JQL In Escalation Service because of failed: Add JQL LIMIT support
I'm voting for these.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@[deleted]- the issues are multiple projects - some have a few hundred issues to update and others have thousands.
I'm using a JQL filter in the automation rule so it:
Neither of these prevent the automation rule exceeding the limits.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Online forums and learning are now in one easy-to-use experience.
By continuing, you accept the updated Community Terms of Use and acknowledge the Privacy Policy. Your public name, photo, and achievements may be publicly visible and available in search engines.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.