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}}
}
}
Error I get from the Audit Log:
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:
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.
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Glad it worked for you!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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.
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.