Jira Timeline planning Automation

[Nikita Vlasov]

I'm trying to achieve the planning of the timeline with Jira Automations.
The goal I want to achieve is (recurring task with a CRON job - everyday at set time):

1. Automation takes a task to process (Only tasks that have Epic (parent), have timeoriginalestimate field (not custom) and is the Status "To Do")
2. Grab it's Epic (parent) and calculate the maximum "Due Date" from all of it's children - maxEpicDueDate
3. Calculate "Start Date" of the triggered issue with next steps:
   • IF Today is greater or equals to maxEpicDueDate, then issue.Start Date should be set to Next business day from Today
   • IF Today is less then maxEpicDueDate, then issue.Start Date should be set to Next business day from maxEpicDueDate
   • it should be capable of monitoring what was the previous task to be able to set next one to the next business day after previous so no issues will overlap
4. Calculate the "Due Date" of the triggered issue with next steps:
   • calculate the amount of days needed to complete the issue based on a Start Date from previous step and the timeoriginalestimate

[Bill Sheboy]

Hi @Nikita Vlasov -- Welcome to the Atlassian Community!

Short answer: what you describe is likely not possible with the features of Jira automation as you want to process issues sequentially and access the prior issues while branching (assuming a specific issue ordering).  Seeing your specific scenario details will confirm that...

For a question like this, context is important for the community to help.  Please post the following:

• what problem are you trying to solve; that is, "why do this?"
• what type of project is this (e.g., company-managed, team-managed, etc.)
• an image of your complete automation rule
• images of any relevant actions / conditions / branches
• an image of the audit log details showing the rule execution
• explain what is not working as expected and why you believe that to be the case

Until we see those...

There are lots of community posts about trying to re-create features of purpose-built, project management tools, such as: sequential processing, cascading date updates with forward-and-backward sync, bulk-dependency shifting, etc.  You may search the community to find those and where others have investigated marketplace apps or external project management tools to help.

Automation rule branches which could be on more than one issue are processed in parallel and asynchronously, with no guarantee of processing order or when the branch will complete...up until the last step of a rule.

Further, the date updates you explain seem unclear.  Why would the Start Dates be updated repeatedly, and potentially updated to have values after the Due Dates?

Kind regards,
Bill

[Nikita Vlasov]

Thank you for your reply!

I have tried to cover as many aspects as I can in the post, so to add to that:
1) The problem I'm trying to solve is planning on a timeline, so for a tasks that have the estimate in time value I want to be able to set start and due dates while they are in the todo queue for the developers. This will resolve the problem when management doesn't understand how much time will each epic take. This will allow us to see the workload by each epic and by each developer and furthermore plan the future releases.

2) The project is team-managed (e.g. the management and developers do the job)

Details to the automation rule:

Image 1: the rule executes as scheduled rule and go a lookup through the all tasks with the similar parent. Then it creates two variables with max due date of all epic tasks and min start date. 

The scheduled trigger set to the one task that I'm testing on, when it will be working, it will be set to the required JQL that will fetch all "To Do" issues with epics assigned and estimates.

Image 2: (Not sure this is required but it works for the case when no Start date is set for the issue) The IF case checks for the "Start Date" field be empty and then executes the logic I described in the original post text.

Image 3,4: The ELSE case starts up for when the "Start Date" is not empty and was already populated. This is the part I can't get to work. Here I try to do a lookup issues through the all "To Do" (in our case "On Deck") tasks to find their rank to know what task was previous. I believe this should work if I can somehow transform the index variable that I got from branch to a number and not a string and then create a variable that will take an issue by its index from the lookupIssues array via lookupIssues.get method. But since it accepts only numbers and not string that returned from the smart variable or the branch variable itself, I can't get the needed issue.

Then I create the IF statement that will check if the Start Date of the current issue is less or equals to todays date and then set the Start Date as described in the original post.

 

Image 5: This part works as it should, It creates a variable that calculates minutes to days + hours and if the number of days are greater then 1, it sets the Due Date to the day the task should end, if the number of days are less then 1, it sets the Due Date to the current day.

Answering to your last question: We do need to repeatedly update the To Do issues so they will change the epic length on a timeline and they can be planned according to the priority.

Let me know if you need the full audit log for this automation.

[Bill Sheboy]

This rule appears to be accessing issues in the lookup using their index value (i.e., a 0-based index) and then repeatedly updating the trigger issue.  Is that what you expected?

As written, this rule uses an Advanced Branch, which iterates over data and not issues.  Thus the Edit Issue action shown within the branch is updating the only issue in scope: the trigger issue.

[Nikita Vlasov]

Thank you for the reply. Yes, I decided to do it this way to iterate through the indexes if the lookup issues so inside of the foreach branch I can take that index and get the current element, but the part where I'm trying to list.get the issue by the index doesn't working, since the smart value always return string, but the get method accepts numbers.

[Bill Sheboy]

As written, I am unclear what this rule is trying to accomplish as it only ever tries to update the trigger issue.  Regardless of that...

The get() function for the {{lookupIssues}} smart value only takes an integer as a parameter.  I recall there are open defects about several automation functions not accepting variables as parameters, including this version of get().  Even converting with asNumber does not work.

[Nikita Vlasov]

The goal of this branch is to check what index current task have, get the previous task by index-1 and look at what is the Due Date of the previous task by index to set the Start Date of the triggered task to next business day. But since there is no option to pass smart variable to the .get() method, I can't achieve this.

[Bill Sheboy]

Reminding you of my first post about the parallel and asynchronous processing nature of branching, I recommend not trying this scenario with the Scheduled Trigger you show.

The documentation does not state if the processing of issues from a Scheduled Trigger also executes in parallel, and I hypothesize it does.  Which takes us back to my first post: this scenario is likely not solvable with a Jira Automation rule.  Doing so will certainly cause problems for the issue data accuracy and rule processing / service limits.

There is a convoluted workaround for the created variable, limitation with the get() function: never create the variable.  That is, only ever use an integer by identifying where the trigger issue is in the lookup results, and store that number in a number-type, custom field (or only use a list of integer indices to the advanced branch).

But those both lead to the original challenge: the issue reads and updates will certainly collide, causing problems looking at and updating issues simultaneously.

If this explanation does not help, I recommend working with your Jira Site Admin to contact the Atlassian Support team.  They may be better able to explain the challenges with this scenario.  https://support.atlassian.com/contact/#/

[Nikita Vlasov]

I see. Your words just confirm my thought, thank you so much @Bill Sheboy for the help.

[Duc Thang TRAN]

Hello @Nikita Vlasov 

This is not fully helpful, but I suggest using these smart values through this link: https://support.atlassian.com/cloud-automation/docs/jira-smart-values-date-and-time/.

Normally, you have everything you need there. It means you can compare dates ,business days, add or subtract dates, etc.

For the max or min value of an epic, you can use the 'lookup issue' smart value.

BR

[Nikita Vlasov]

Thanks for your reply!

Yes, indeed, I did used 'lookup issue' for finding max and min values of the all children tasks from the epic. But the biggest flaw in this automation that I can't handle the path of the script e.g. I don't know how the script will behave in each run and what task will be executed first, second, etc. To solve this I tried to use 'lookup issue' with "SORT BY Rank" to sort them by ranking from the timeline (that's the intended way of sorting issues priority). The issue that lookup issue return a string value like an every and each smart variable in the automation. BUT the List function to get an item by index (lookupIssues.get(index)) ASKING for a number value which can't be retrieved hence all smart variables are strings and making it var.asNumber does not solve the issue, also making the math expression to do val * 1 return an error. So I cant effectively track what rank does current executed issue have to get a previous issue "Due Date".