Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Automation: Copy values from parent record into Description of new record upon Move

Josh Davis
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 29, 2022

I need to be able to copy the values from 3 existing multi-line open text custom fields from one project issue record into the description field of the new issue record when the record is "moved" from it's parent project into a new one.  This is because the destination project does not contain the same custom fields, and we don't need them there.  I've read through the advanced documentation on how to do this, but still not getting the value to carry over.  Any help to get this working correctly would be greatly appreciated.  Thanks!


{
"fields": {
"description": {{issue.parent.customfield_10158}}
{{issue.parent.customfield_10157}}
{{issue.parent.customfield_10054}}
}
}

 image.png

 

Error I get from the Audit Log:

image.png

2 answers

1 accepted

1 vote
Answer accepted
Darryl Lee
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 29, 2022

Hi!

The main problem is what @Colton.Kosicek mentioned last. You don't need to use issue.parent, because that's for subtasks, etc.

To avoid confusion, instead of "parent", let's call it the original project. And because Description is a pretty standard field, you don't even need to use Advanced Field Editing where you get all into the JSON. (As much as I love that kind of stuff.)

The key thing is, when you move a ticket to a project that doesn't have the same fields visible, those field values are still there. And in Automation you can reference them like any other Smart Value for issue fields .

So then, this works just fine:

Screen Shot 2022-03-29 at 6.27.27 PM.png

Where my multi-line fields from the original project are "Implementation Plan", "Backout Plan", and "Test plan".

Oh, and btw your rule assumes the Description in the original project is empty. If, perchance, it is not, and you don't want to overwrite it, you might want to use:

{{issue.description}}
{{issue."Implementation Plan"}}
{{issue."Backout Plan"}}
{{issue."Test plan"}}

Let me know if this works! I tested and it seems to do the trick for me. 

Josh Davis
I'm New Here
I'm New Here
Those new to the Atlassian Community have posted less than three times. Give them a warm welcome!
March 31, 2022

Thanks @Darryl Lee - this is exactly what I was looking for.  It worked! 

You caught that my description field was going to be blank.  That's correct, because the description field is not used in the source project, but will need to be transferred to the destination project via existing fields.

image.png

Like Darryl Lee likes this
Darryl Lee
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
April 1, 2022

Glad it worked for you!

1 vote
Colton.Kosicek March 29, 2022

I have a few suggestions:

We'll start with positive ideas - have you tried to set the issuefields as variables first and then placing into the description.  This will allow them to be stored.

 

Alternative solution - if the trigger is upon moving the story from one project to another where the fields do not exist in the other than i would assume we would have already of lost those data points.  Good thing is that most fields exist on an issuetype if you see them or not it's more of a matter of "screen schemes" visualizing the fields than data loss. Assuming this is the case for your space than the data may still be there just needs a cleaner approach with variables.  You can log the variables in the audit logs to see what information is being captured when an error exists.

 

Without more details it is hard to say if we have the right issue.parent.customfield.... identified or not.  Variables can help you double check if there is the data there or not that you are expecting.  My assumption is that you are pulling custom fields from the same issue based off of your comments above.  If so  you probably do not need the "PARENT" as that would be referring to the JIRA EPIC most likely or Story/Task if you are looking at sub-tasks.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events