nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Assigning issue fields in a for loop based on the previous issue

Ali Kashanian_ix8dwk

Hello,

I am trying to iterate though sub-tasks of an issue and assign Start and Due dates of them when the parent transitions to a certain status. The issue and its sub-tasks are imported via CSV file and their issue numbers are ordered without any gap. The sub-tasks are related to each other and one task is blocked by the one task before it and blocks the one task after it, except the first and last ones. I am trying to iterate through the sub-tasks and calculate the Start date based on the previous sub-task's Due date + one business day and Due date based on the calculated Start data and original estimate. I tried using Variables, but it seems like the variables are only initiated once and won't change later (I may be wrong and not using them properly). I tried to look for anyway to get the previously iterated issue in the for loop, but to no avail. I also tried to use automation loop, but seems like with my license tier, it's limited to 10 and I couldn't find any way to change that.

I was wondering if there was anyway to pull the above scenario off?

Kind regards,

Ali

Accepted answers

Bill Sheboy

Hi @Ali Kashanian -- Welcome to the Atlassian Community!

For a question like this, I recommend posting images of your complete rule and the audit log details showing the rule execution. Those will provide context for the community to offer more relevant suggestions for your scenario.

Until we see those...

The scenario you describe is quite difficult to solve with automation for Jira rules. The primary reason is that branches process the issues asynchronously and in parallel: there is no way to currently run them sequentially. In fact, there is no guarantee that a branch will finish up until the last step in the rule...And so you cannot rely upon the outcome of a branch to be used in later steps. This is apparently by design to improve rule performance, scalability, prevent blocking, etc.

I hypothesize a work-around for your scenario would be to process each sub-task, one at a time in a rule...and the last step in the rule performs some action that leads to re-triggering the rule for the next sub-task. Update: due to the looping checks for recursion, this approach would not work when the issue count is >= 10.

Kind regards,
Bill

All comments

Bill Sheboy

Hi @Ali Kashanian -- Welcome to the Atlassian Community!

Until we see those...

Kind regards,
Bill

Trudy P Claspill

Just a side note vs. an answer:

Regardless of user tier Automations are limited to 10 recursive triggers. That information is in this document:

https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

Bill Sheboy

Thanks, @Trudy P Claspill as I forgot about that one :^)

Ali Kashanian_ix8dwk

Hi Bill,

Thanks for the reply. If the for loop is running in parallel, the using that will be off the table.

I also setup 3 rules to run them for each sub-task:

1. Parent: When Issue transitioned to "In Progress" -> For each unblocked issue > Unset and then Set the Start date to the TriggerIssue.Start Date (customfield_xxxxx)

2. Sub-tasks: When the field "Start Date" value added -> I calculate the Original Estimate in business days and then add it to Start Date. Then unset and set Due Date to the final value.

3. Sub-tasks: When the field "Due Date" value added -> For each blocked issue in the Issue Links > Set the "Start Date" to TriggerIssue.Due Date + 1 Business Day.

I have 16 sub-tasks to run through and as I mentioned, I get a loop error once it hits 10 recursion. The sub-tasks are NP-70 through NP-85:

Please let me know if you need more information to clarify the situation.

Kind regards,

Ali

Bill Sheboy

First thing, thanks again for the reminder about the looping checks. The idea I originally suggested (i.e., multiple rules) cannot work for your scenario due to the number of subtasks. I will update my earlier posts to note this.

Next thing: this scenario is quite brittle for a tool like Jira. Unlike a project management tool, there is no built-in time/predecessor handling. Making this more challenging: what happens if someone manually edits a date in the middle of the chain, or adds/deletes a subtask?

I suspect there are marketplace addons for this capability...and I recall a couple community posts of Atlassian hackathon experiments to add this feature to roadmaps/timelines.

So, how to proceed...

It seems there are 2 possible cases for your scenario:

An unknown number of subtasks for an issue, have predecessor relationships, different effort forecasts, and so dynamic date relationships for Start Date and Due Date. I do not believe this can be handled with built-in features, and instead might require using a web request to call code outside of Jira to make the changes...or a marketplace addon.
An unknown number of subtasks where the Start Date and Due Date are set at create, and the desire is to shift them by a specific amount. The predecessor can be ignored as that was handled at issue create. This can be handled by a simple branch over the subtasks to make the adjustments.

There may be an edge case to #1: when there are <= 20 subtasks, one could capture the Start Date and Due Dates for all current subtasks in the new Lookup Table action (sourced from an initial Lookup Issues call to order the subtasks). Then using the saved Lookup Table, update the subtasks in a single loop as the predecessor data could be read directly from the table. This seems an even more brittle solution than what I originally suggested.

Ali Kashanian_ix8dwk

Thank you again, Bill.

I ended up implementing a workaround. I added a number field named Accumulated Estimate and calculate it in Excel. Long story short, now each sub-task can add that number to {{TriggerIssue.Start date}} and set their own start date, then calculate Due date based on that. This way, each sub-task calculation can run in parallel.

I modified the automation and everything looks fine now.

Kind regards,

Ali

Ali Kashanian_ix8dwk

Thanks Trudy,

This link helped a lot in refactoring the process.

Kind regards,

Ali

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

cloud

jira-software

jira-software-cloud