Get field value for sub-task from parent's epic

[Rick Crow]

I've scoured the posts here and more broadly and have yet to come up with a definitive answer as to whether it's possible to automate setting the value of a sub-task field by targeting a field in its parent's epic field. I understand that I can sync the value of an Epic's field to a story or other issue in that Epic so that it would be directly available to the story's sub-tasks, but I'm hoping I can avoid that and directly capture the value from the Epic to the sub-task.

Possible without third-party apps?

@Simmo ?

[Rick Crow · Accepted solution]

Thanks, all. Until the lookup action supports custom fields then, it looks like the answer to my original question is no, there is no way to directly access an epic field's value from a sub-task. My solution is now to copy the needed value from the epic to the parent issue of the sub-task so it can be accessed when needed.

[John Funk]

Hi Rick,

Can you give us an exact scenario? But I am hoping this can be done with Automation for Jira. 

[Rick Crow]

Sure, John ... thanks for asking.

This is for a project that will have a set of repeatable tasks per client that will happen once a year. Each year our internal team prepares a presentation for the client visit. To support this, I've created a few date fields and one date 'offset' field that will be used to help calculate the due dates for each task.

Epics are used to represent the annual client visit. The Epic has an 'Earliest visit date' field. The individual tasks that need to be carried out to prepare the presentation for the annual visit are issues within that Epic. So far, I'm good ... everything is working. The trick is that some of these issues need to be further broken down to allow for multiple people satisfying the requirements for a single task and so sub-tasks come into play ... which also need unique due dates and therefore a calculation based on the 'Earliest visit date' field in its parent's Epic.

So:

1. Epic: 'Earliest visit date' field
2. Task: 'Visit task offset' numeric field used with 'Earliest visit date' field in Epic to calculate individual task 'Due date' field.
3. Sub-task: Same as Task ... same fields and calculations, but now the 'Confirmed visit date' field is not in the direct parent.

Of course, I could also just avoid the use of sub-tasks and repeat the appropriate tasks (n) times with a modified/extended summary field to differentiate them, but I'd prefer to leverage sub-tasks to keep things cleaner at the primary task level.

[Rick Crow]

In case it's helpful, here's what I'm using to do the magic between the tasks and epics (modifying the task due date field):

{{issue.epic.Earliest visit date.minusBusinessDays(issue.Visit task offset)}}

This, of course, doesn't work ... but it illustrates what I'd like to accomplish with the sub-tasks:

{{issue.parent.epic.Earliest visit date.minusBusinessDays(issue.Visit task offset)}} 

[Bill Sheboy]

Hi @Rick Crow 

When do you create the sub-tasks, with the task creation or at some later timeframe?

And, have you confirmed the names of the smart values match your custom fields?  (Sometimes they are different and so the custom field ID is needed.)  To find those, try the steps in this article: https://support.atlassian.com/jira-software-cloud/docs/find-the-smart-value-for-a-field/

Regardless of when you create the sub-tasks, you could use a branch to the epic to capture the "Earliest visit date" in a created variable, and then do math on that to get what you need.  A key thing is to convert the variable to a date before doing the math.

For example, if you create the variable and named it varEarliestVisitDate, you would use:

{{varEarliestVisitDate.toDate}}

Kind regards,
Bill

[Rick Crow]

Hi, Bill ... thanks for the response. Your comments seem to align with a thread I found after posting this: https://community.atlassian.com/t5/Automation-questions/Transition-Initiative-to-In-Progress-when-Epic-starts/qaq-p/1724671

The triggering issue will be the Epic, so given what I've come up with so far, where should I create the variable so that it's in scope when called?

Note that some of the complexity you see in the automation below is due to the fact that I have two different date fields that will be used to calculate task due dates depending on whether the visit date is 'penciled in' or confirmed. Once confirmed, the automation can be run again to adjust the dates to the new date that may be introduced.

[Rick Crow]

By the way, I should have mentioned that the other problem I'm having is in simply targeting the sub-task from the triggering epic issue ... which may ultimately be my biggest problem as the rule as you see it here fails to target the sub-tasks.

What is the appropriate way to target a sub-task in this scenario?

[Bill Sheboy]

Hi, Rick.  I'm going to try to answer the questions you note, so let me know if I miss something or misunderstand your use case.

a) Where to put the create variable:

You note the intended trigger issue is an epic, so I suggest adding a condition right after the trigger to check that.

Next, as the rule is triggered for an epic, you do not need the created variable as you can use the field directly from it with:

{{triggerIssue.Earliest visit date}}

b) Sub-task handling for rules trigger from the epic

The reason your rule doesn't update sub-tasks is the trigger issue is an epic, and one of your branches is trying to reach sub-tasks of the included stories/tasks: that cannot work as automation rules cannot nest branches.

One work-around for this is to build rules to operate on parent/child pairs, and then let one rule trigger another.  For example:

1. Rule with epic issue triggered and can update its child story/task/bug issues
2. Rule with story/task/bug issue triggered and can update their sub-tasks.

To make this work, Rule 1 makes a change which can lead to triggering Rule 2, and in the details of Rule 2, enable the option "Allow Rule Trigger".

There is a more complex work-around to do epic-to-sub-task synch in one rule, and it involves building a dynamic JQL statement from the sub-task lists of the story/task/bug issues.  I tend to avoid that one as it is slow, difficult to debug, and could exceed the 100 issue limit for rule processing.

[Rick Crow]

Thanks, Bill. I get and agree with your response to a). But with b) the value I need for the sub-task needs to be calculated from a field that's currently only available in the Epic. I understand triggering a rule from another, but I don't see how I'm able to pass the value from the Epic through to the sub-task with this approach.

What am I missing?

[Bill Sheboy]

You seemed to be adjusting task dates with a value stored in the task: Visit Task Offset.  Is that correct?  If so, you could reverse that value in order to find the Epic's date.  For example when a story triggers a rule to update their sub-tasks...

Epic's date = {{issue.duedate.plusBusinessDays(issue.Visit task offset)}}

Then use that value to update the sub-task's due date, with your adjustments.

[Simmo]

Hey all,

I'm late to the party because of timezones and all of that, looks like there has been some excellent brainstorming going on here. We might have been able to solve this easily with the Lookup issues action but it doesn't support custom fields yet.

So I think Bills last suggestion is the best. You'll have to source this from a field on the task. If this isn't an option or you don't want a field on here that does this, you could maybe try storing it on the entity properties of the task. That is, copying it from the epic to the task. and then you'll just need to keep it updated should it change on the Epic.

[John Funk]

Thanks for jumping in @Bill Sheboy and @Simmo !!