Hi there,
I am looking to use Jira automation to update ticket dates for me
I have a sequence of tickets, with a set start date relationship to the due date of a launch. i am wondering, because every ticket has a duration and a start date relative to the final task due date, can i use Jira Automation to allow me to edit the due date of the final task (or any if possible) and Automation does the maths to calculate each previous tasks duration, and start date relative to the updated ticket to accurately update all tickets. this would save me from updating each ticket manually as its very time consuming
Does anyone know what that would look like in Automation?
Any help is greatly appreciated! Thanks
Hi @Cooper -- Welcome to the Atlassian Community!
Short answer: If all of the subtasks have the same "duration" and you know the relative amount to shift the dates, that can be done with an automation rule branch. Otherwise, solving this is quite difficult, and perhaps impossible with built-in Jira features.
When automation rules branch over work items, they process in parallel and asynchronously. Currently, there is no sequential branching for a single rule. What this means for your scenario is a rule cannot "walk the chain" to update the subtasks, one-by-one in order.
Thus, if they all have the exact same duration and you know the amount to shift the dates, the order of processing does not matter and can be done with a rule branch over the subtasks.
There is an edge case where the work items can be processed in order sequentially: when there are fewer than 10 work items in the entire chain, two rules may be used and the second rule recursively processes each until done. This approach is a bit risky due to possible rule errors, timing problems, and any Atlassian automation outages "breaking" the chain of processing.
Kind regards,
Bill
Hey Bill, thank you for the explanation.
Would that mean, even if tasks have a different duration, I can use an automation to update all of the due dates by an amount, rather than a date? For example, instead of saying the new end date is April 6th, can I say the final due date is +100 days for example, and use an automation to just add 100 days to every individual tasks due date? That way it doesn't have to run in a sequence, but can rather do all actions in one, by simply adding an amount of days to every due date?
Because the process will be repeated, activity durations will stay the same. So, all activities adding 100 days to the deadline can keep the same order and alignment of activities. Thanks!
Kind regards,
Cooper
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Cooper
Yes, if you are adding a known amount to each work item's date to shift it, the processing order will not matter. The date increment functions could be used:
Please note that rule branching is limited to up to 100 items, and if you have more this approach would not work. Also, watch for any rule failures / errors during the looping; this would require a cleanup to handle any dates that did not change.
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 Bill.
I don't believe our biggest processes will exceed 100 items, so that could work.
Using those smart values, is it possible to apply the amount to an epic, and all subsequent child tasks and subtasks within? How might I structure the automation to acknowledge this
Thanks
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Cooper - Welcome to the Atlassian Community!
Are you saying the tasks will be of various lengths and not consistent for each time created? In other orders Task A starts 20 business days before Launch Date and is Due 18 business days before Launch Date. Task B starts 18 business days before Launch Date and is Due 15 business days before Launch Date, etc.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey John, thanks for the response!
There are various tasks in a process, that will always be the same length, with the process being repeated several times.
The only thing that will change is the due dates.
Say i have 5 launches, that all are the same process. The process has 9 steps, and lasts 1 week all up. I will be duplicating a Launch as the steps are the same. My goal is to change the due date of the launch, and automation will know the duration of each step, and its start date relative to the due date. i am hoping it can make those changes for me.
Thank you
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Yes, I do the same thing (if I am understanding you correctly) every day.
So, I have an automation rule based on a parent level work item created (trigger). That work item has a due date in it. There are are using some conditions that further define that parent type, so that I would have multiple rules based on the same thing but with different conditions. For example rule 1 would be for Email campaign and have a different set of durations for the tasks. Rule 2 would be for an Ad campaign with a different set of durations, etc.
Then after the condition(s), I have a series of actions that create the work items. The due date would have a value some something like {{triggerIssue.duedate.minusBusinessDays(10)
This says to create the first task with a due date of 10 business days prior to the due date of the parent.
Task two would have a due date of say 8 business days prior, etc.
I also use start dates in a similar fashion. For task one above the due date is 10 business days prior to the parent and the start date would 12 business days prior.
Does that make sense? Is that what you are looking for?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi John, thanks for the answer.
That does make sense, and is certainly a viable option. The only issue we face is how time consuming it will be, as our process is comprised of 20 ish steps, so it would require that many different rules or branches in the automation to tell Jira to deduct that many number of days from the trigger issue due date.
I am hoping there is a way, potentially through using create a variable, to get jira to be able to identify the date offset that an epic experiences, and can apply the same offset to all children tasks.
I have something like this in mind:
Create variable - DateOffset
{{issue.duedate.diff(issue.previous.duedate).days}}
For: Children
Then: Edit work item fields - due date
{{#if(issue.duedate)}}{{issue.duedate.plusDays(var.dateOffset)}}{{/}}
I think my smart text is not quite right, as at the moment updating the epic due date will edit all of the child due dates, but only to delete them. It's not updating to match the date offset unfortunately
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Have you tried just using: {{issue.duedate.plusDays(var.dateOffset)}}
Here's a longer post with different scenarios, but it might help.
But that would only give you one set of days, right? You might consider creating a lookupTable and then use the value in the Variable. And then the Variable in the Edit field.
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 code, I gave it a go but unfortunately it results the same where I update the epic's due date, and all children tasks simply have their due dates deleted rather than updated
As for that link, I don't have the required permissions to view the page. I think its been archived maybe
Do you have any ideas why the due dates would simply be getting deleted for children tasks?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
The Due dates are getting deleted because the code there is returning nothing, so it's updating the field with no value.
Sorry about the link - it is in a Moderator status. Try this one:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Variables may be converted with asNumber for use in some functions and not others. To learn more, please see this article I wrote which covers the different types of functions and possible workarounds to use variables a parameters:
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
So is it the code of the dateOffset that's returning nothing? The automation is unable to calculate the number of days an epic has had its due date delayed by?
Thanks for that new link, looks promising. I'll work to see if I can sculpt it to fit my need. Is there a chance that setting an entity property for the issue will help me? I see it mentioned but not sure how applicable it is
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi @Cooper -- Earlier you mentioned using the same value / increment for all the work items. If that still applies, you could store that as a variable and use it for all:
{{issue.duedate.plusDays(yourVariableName.asNumber)}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hey @Bill Sheboy , yes it does still apply. there is 1 process that will always be the same, and therefore have the same tasks and subtasks within, so whatever the final due date of the epic will become, the final due date of the final task within will match it, and all previous activities will be in the same order before it. Therefore yes, all activities will remain in the same order and have the exact same due date update.
I'll give that a go now! Thank you
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
@Bill Sheboy unfortunately, the same result where all due date of the children tasks are being removed.
I look at the audit log and see success, where the breakdown notes the tickets are being updated. we can confirm this because the get removed.
However, also, the audit log shows a collection of different audit logs, all for this same rule. they then show 'no actions performed' for each of the child items (which is 5, so there's 5 no actions performed). after this, there's another 1 audit log, which is another success. so from one trigger action, updating the epic due date, there is a success, 5 no actions, and another success.
It's most strange I wonder if the 7 audits instead of just 1 is partly why I keep seeing a failure. Thoughts?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Let's align on some context...please post images of:
One more thing to consider: Due Dates are just date type, but some date / time functions force the value to a date / time type. For a Due Date, we can truncate off the time by formatting as text when setting it, such as with this:
{{issue.duedate.plusDays(yourVariableName.asNumber).jiraDate}}
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
1. Full Rule - Note I have also attempted without the second branch in case 'For: Children' did not apply to subtasks within the tasks. The Grandchildren effectively.
2. Create Variable
3. Edit work item action - note, the smart value for the second edit work item is identical
4. Audit log - note, I complete one trigger action, updating edit epic due date, yet 7 audits exist.
4a. The first (chronologically) of the two successful audits - note, the details of the second audit are identical
4b. one of the 5 'no actions performed' audits - note, all of the five unsuccessful audits are identical, except the task in which the action was not performed at is each of the 5 activities listed in the 'Edit Work Item' section of image 4a.
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.