Cloning sub-tasks using jira automation

[Mary Mark]

Hello Atlassian Community. 

Looking for some help to clone sub-tasks tickets from the parent ticket and then update a field values based on condition.

I am checking if the cloned ticked for a 2 level cascade field called category/sub-category contains the following values: Contracting Third Party - Change / NA to MGA transfer

If the new cloned sub-task ticket contains those values then update/edit field values:

{
"fields": {
"customfield_10182" : { "value": "Remun - Block of Business Transfers", "child": { "value" : "NA to MGA transfer"} }
}
}

However, this also updates and edits the category/sub-category of the original sub-task ticket but I only want it to apply to the new cloned sub-task ticket without changing original value of the sub-task ticket

For example:

original sub-task ticket contains values: Contracting Third Party - Change / NA to MGA transfer

New cloned sub-task ticket contains values: Contracting Third Party - Change / NA to MGA transfer (Rule checks to see if this is true, then update values to: Remun - Block of Business Transfers / NA to MGA transfer)

but do not update the original sub-task ticket.

This is my automation rule:

Thank you.

M

[Bill Sheboy]

Hi @Mary Mark 

How is this related to the similar question which you have already posted a few days ago:

https://community.atlassian.com/t5/Jira-Software-questions/Using-Jira-automation-to-clone-sub-task-and-update-field-values/qaq-p/2510914

Kind regards,
Bill

[Mary Mark]

Hi @Bill Sheboy 

I actually meant it for the other post as well but I had issues opening the link. Would you be able to take a look why the new cloned subtasks are not updating the custom field values accordingly. I also did a search online and found that there is a create variable action for subtasks that is not available for jira automation data center but this feature is available on jira cloud. I am wondering could there be limitation with how jira automation works for cloning subtasks and updating values on new cloned tickets. 

Apologies for the confusion

Mary

[Bill Sheboy]

First thing, in which post do you want to work on this symptom: this one or the other post?  Knowing that will help focus the community conversation, and you can close out the other one (if it is a duplicate).  Thanks!

[Mary Mark]

This post works!! I’ll get the other closed. Thank you!! 

[Bill Sheboy]

Awesome!  On to the follow-up questions...

For some context, please post an image of your complete automation rule in one image.  You can do that with a screen capture tool, or browser addon which does scrolling page capture.  If there are any issue create or edit actions, add separate images for those.

Then post an image of the audit log details showing the rule execution which does not work as you expect.

Finally, please describe what is not working as you expect, referencing the specific Jira issues and fields involved.

[Mary Mark]

Hi @Bill Sheboy 

Here is the complete image of the automation rule

The issue in question is this section: For Sub-tasks

Here are the detail actions

Logs attached.

The tickets / issues created.

This is the original parent ticket. Issue 14583 created. 

Original subtask: DCS-14584

Subtask ticket: 14584

The category / sub-category values should remain as: Third Party - Contracting / NA to MGA Transfer but after cloning the sub-task to the new parent subtask ticket, the 1st level category of the original sub-task ticket got changed from Third Party - Contracting TO: Remun - Block of Business Transfers

This is the clone ticket of the parent: DCS-14590

The clone subtask ticket is: DCS-14591

The values for Category/Sub-Category is correct.

I am not sure in the rule if I am using the right branch. I am thinking whether the automation is confused with the updating the field values for the sub-task from the parent ticket with the sub-task from the new cloned ticket.

The category/sub-category values of the sub-task ticket on the original parent ticket should not change/get updated.

Thank you!

Mary

[Bill Sheboy]

Thank you for all of those details, Mary!  That is a complex rule, that I suspect is not working as you intended...due to a couple of things.

First, rule branches which could be on more than one thing (e.g., on linked issues, on subtasks, etc.) are processed in parallel and asynchronously, relative to the rest of the rule.  This means that the branch will not complete before the next rule step.  Indeed, the branch may not finish up until the last step of the rule.

Your rule contains several such branches, and so that will certainly lead to unpredictable behavior.

Next, when an issue is created inside of an if/else or branch structure, the smart values for the most recently created issues are not reliable, because they happened at another scope.  There is a work-around for that for Jira Cloud, but not for Jira Server automation.

My recommendation is to pause and map out what you want this rule to accomplish.  That may then require creating multiple rules rather than one large one.  Thus one rule may perform an action which leads to the triggering of another rule.

As a start, I recommend splitting your rule by Transfer Type, adding that condition to the JQL, and so you would have multiple, smaller scheduled trigger rules.

[Mary Mark]

Hi @Bill Sheboy 

Thank you so much for reviewing. I did break this up. Instead I focused on the subtask piece in a separate automation rule. However, cloning the subtasks works. It’s when you come to update the values that it’s not correct. 

you mentioned about a workaround for jira cloud but not for jira data center. Can you share with me what this workaround is? 

Can you help to clarify why that would be the case?

Thanks

Mary

[Bill Sheboy]

For Jira Cloud there is an action for Create Variable, that allows saving the key for the newly created issue for later use.  That can work-around the scoping issue for if/else structures.

Back to your rule: when you not the value update is not working, what is happening?  Would you please post an image of your new, smaller rule and its audit log showing execution details?

[Mary Mark]

Hi @Bill Sheboy 

Please see screenshot attached.

The ticket was successfully cloned but the updates to the customfield values is not working and do not get updated. 

[Bill Sheboy]

Recalling that thing I mentioned about branches, scope, and "most recently created"...your second branch likely cannot work because the rule cannot "see" there was an issue created.

What is happening in that last Edit Issue action?

Could the changes be done at the same time as the cloning, which would eliminate the problem?

[Mary Mark]

Hi @Bill Sheboy 

I’ve tried the clone and then edit at the same time. The problem is that the original subtask ticket also gets updated/edited which is not what I want. The edits are to be apply to new clone subtask ticket. 

Is this feasible for subtasks? I’m wondering if this cannot be done because there is no create variable feature in jira datacenter. If you have any idea how this can work please advise.

Thank you and much appreciated

[Bill Sheboy]

What edit are you trying to make to the newly created Subtask? 

Knowing that may help to figure out a way to do that at the same time as it is created...eliminating the need for the separate edit.

[Mary Mark]

On the new subtask ticket, i am trying to edit the custom field category/subcategory to a different value. This custom field is a 2 level select cascading field. 

[Bill Sheboy]

I believe you can do that at the same time as the clone action, using an advanced edit with JSON.  Have you tried that?

[Mary Mark]

I’m not familiar with that do you have an example? How would I reference the new subtask to update values in the json? 

[Bill Sheboy]

You appear to already be doing that in your Edit Issue action.  That JSON could be copied and used in the Clone Issue action instead.  When cloning, any field values can be replaced (rather than copied) if provided in the action.

Here is the advanced edit with JSON reference, just in case you want to check your expression: https://support.atlassian.com/cloud-automation/docs/advanced-field-editing-using-json/#Cascading-select-custom-field

[Mary Mark]

I also tried this and the new cloned ticket reflects the updated values however the original sub-task values also got updated too.