Automation rule - copy value from latest sub task

[Nadeem Zakir]

Hi,

Is there an automation rule that I can create that takes the value of a previous sub-task custom field and copy it to its parent? 

For example, we have a parent issue with 3 identical sub-tasks and fields.  All issues, parent and sub tasks have a select list called “Result” with the values “Pass, Fail, Ignore”.

Sub task 1 has “result=pass”, sub-task 2 has “result=ignore” and sub-task 3 has “result=fail”.

The value for sub-task 3 (fail) copies itself to the parent issue field.  So both parent and sub-task 3 show the result as fail.  This rule is working fine, copying a value from the latest sub-task to a parent issue.

However, say we drop or delete sub-task 3.  We then want to update the value of the parent result of the last sub task, so in our case, sub-task 2 with result ignore.

Is this possible, any branch rule or clever JQL that can achieve this?

thanks

[Nadeem Zakir · Accepted solution]

1. It is possible to achieve that, but it will require multiple rules due to the way Jira/Automation currently works

   1. Prerequisites
      • Create another custom field which we use to keep track of parent tasks with dropped sub-tasks. I created a Text Field (Single line) with the name 'ST dropped'
2. Rule 1
   • Trigger: Issue Transitioned
   • Condition: Issue fields condition (If Issue Type equals Sub-task)
   • Action: For Parent - Edit Issue (Set 'ST dropped' to 1)
3. Rule 2
   • Enable the Allow rule trigger option for this rule
   • Trigger: Field value changed (ST dropped)
   • Condition: Issue fields condition (If 'ST dropped' equals 1)
   • Action: Send Web Request
     • Enable the 'Wait for response' option
     • Use the below as Webhook URL

<BaseURL>/rest/api/2/search/?jql=%22Parent%22={{issue}}%20and%20status%20!%3D%20dropped%20Order%20by%20key%20desc&fields=customfield_13501

Replace <BaseURL> with your base URL. Replace customfield_XXXXX with the ID of your Result custom field (eg. customfield_10600)

1. • • Make sure to fill in the appropriate Headers as well (you need to your own Authorization token value)
   • Action: Edit issue
     • Clear 'ST dropped'
     • Update Result with the following smart value

{{webhookResponse.body.issues.fields.customfield_XXXXX.value.first}}

The rules works as below

1. When a subtask is dropped, the 'ST dropped' custom field for the parent task will be updated to 1
2. The 2nd rule is triggered when 'ST dropped' is changed to 1. It will perform the following
   • Run a JQL search for all subtasks under this parent in descending order, returning only the value of Result custom field
   • Updates the Parent task with the first value of Result custom field from all subtasks. Because the search result is ordered by key, the first result should be the last sub-task of the parent

[Trudy Claspill]

Hello @Nadeem Zakir 

How do you identify which subtask is "last"? Is it based on Creation date or something else?

[Nadeem Zakir]

Correct, based on creation date.

[Trudy Claspill]

How would you "drop" a subtask? Is "dropping" the subtask the same as deleting the subtask issue? 

[Nadeem Zakir]

Dropping in our case, meaning a workflow status, similar to Done, but instead we Drop them, so thats the last status.  So technically, say out of the 3 sub tasks, we transition sub task 3 to drop.  This would then copy the Result field from sub task 2 to the parent.  You can ignore what I wrote earlier about deleting the sub task.

[Trudy Claspill]

Something like this should work.

When an issue is Dropped

And that issue is a sub task

Find its Parent issue

Then look up all the subtasks for that parent where the subtasks are not Dropped
Order these by creation date in descending order so the first on in the list is the most recently created subtask

Make sure the result set has at least one issue in it.

Set the parent issue Result field to match the Result field of the first issue in the result set (the most recently created subtask)

TRIGGER: Issue Transitioned
  To Status: Drop

CONDITION: Field Value
  Field: Issue Type
  Comparison: equals
  Value: Sub-task

BRANCH: Related Issues: Parent

  ACTION: Lookup Issues
    JQL: parent = {{issue.key}} and status != Drop order by Created desc

  CONDITION: Advanced Compare
    First Value: {{lookupIssues.size}}
    Comparison: is greater than
    Second value: 0

  ACTION: Edit issue
    Field: Result
    Value: {{lookupIssues.first.Result}}

[Ali Mughal]

What does it mean to, "drop" a subtask? Does "dropping" the subtask mean that the subtask problem has been deleted?

[Bill Sheboy]

HI @Trudy Claspill 

It appears that @Nadeem Zakir is using Jira Server, and not Jira Data Center or Jira Cloud.  And so the action Lookup Issues is not available.

Kind regards,
Bill

[Nadeem Zakir]

Hi, sorry should have made it clearer, we are using Jira Data Centre.

[Nadeem Zakir]

@Trudy Claspill I think your suggestion is on the right track.  I have created an automation rule as you suggested using lookupissues, the rule runs and says success but the "result" field at the parent level gets cleared after I transition the sub task to drop rather than taking the last sub tasks "result" value.

[Trudy Claspill]

Can you show us the rule you constructed and the Audit Log for the rule execution?

Where I used "Result" in the smart values you would need to use the actual name of your field. What is the actual name of the field, with the correct capitalization?

[Nadeem Zakir]

Hi, the actual custom field is called Attestation Result

[Bill Sheboy]

Thanks for that information!

Would you also please show an image of the details of the Edit Issue Fields action?

[Trudy Claspill]

Can you show us the full smart value you are using to set the field?

Did issue 13772 have a value for Attestation Result?

Could there be subtask that don't have a value for that field? If the field has no value, do you still want the parent issue field set to match? Or do you want the parent field set to match for the latest subtask that does have a value?

[Nadeem Zakir]

Hi @Trudy Claspill @Bill Sheboy  thanks both for helping out.  The field Attestation result is always populated on the sub task and the parent.  It copies from the sub task to the parent.  Have attached more images.

[Bill Sheboy]

Let's please get very specific on the symptom.  This is what you stated earlier:

...the rule runs and says success but the "result" field at the parent level gets cleared after I transition the sub task to drop rather than taking the last sub tasks "result" value.

What exactly do you mean by "the last sub task"?  Is this based on the created date, the summary, or some other field?

The current rule uses JQL and Lookup Issues to find the last created subtask which has not been Dropped.

[Trudy Claspill]

Trudy Claspill

COMMUNITY LEADER

Sep 15, 2023

Hello @Nadeem Zakir 

How do you identify which subtask is "last"? Is it based on Creation date or something else?

nzSep 15, 2023

Correct, based on creation date.

Like

[Bill Sheboy]

Thanks, Trudy!  I saw those posts but when I noted the symptom I wanted to confirm shared understanding.

[Trudy Claspill]

@Nadeem Zakir 

What type of field is Attestation Result?

Can you add a Log action after the condition where you check the lookupIssues.size result, and print to the Audit Log the value in the smart value you are using - {{lookupIssues.first.Attestation Result}}

Then trigger the rule agains and show us the Audit Log again?

[Nadeem Zakir]

if you look at the Control issue, which is the parent. That has two sub-tasks, one is done and one is in progress. Both those sub tasks have an attestation result, “no instance in the period” and “pass” respectively. Sometimes, we need to transition a sub-task to Dropped, in this case, lets say the sub task that has passed.

What we are trying to achieve then, is for the attestation result to be taken from the other sub-task with the value “no instance in the period” and have that copied over to the attestation result field on the parent. Its the same field for both sub task and parent, under the attestation tab.

How do we determine what sub task to use? We use the sub task that was created last, using the created date. So we could end up with 8 sub tasks. created in order, 1,2,3,4,5,6,7 and 8. Sub task 8 gets dropped so the rule copies the attestation result of sub task 7 to the parent.

[Nadeem Zakir]

no errors in the log

[Trudy Claspill]

The log is not printing a value for Attestation Result for issue 13772.

So, either the smart value being used is incorrect, or there is something about that type of field that requires the user of a different smart value.

You can try using the custom field id instead:

{{lookupIssues.first.customfield_13501}}

Also, what type of field is Attestation Result?

[Nadeem Zakir]

Its a single choice select list, I have tried using the name and the ID of the field.  So still no luck.

[Nadeem Zakir]

@Trudy Claspill @Bill Sheboy 

Thank you for your assistance, Atlassian supported provided a way on how to achieve what I wanted, works perfectly. Have posted the answer above.

thanks

[Nadeem Zakir]

wrong answer accepted