Automatic task cloning after project creation
Asked by Potip Serhii:

Hi, can you please tell me if it is possible to clone a task from project A into a newly created project B through automation? I tried to do it through the trigger The project was created, but I don't understand how to proceed.


Answers:
author: Darryl Lee
body: So I didn't like having to make [@Potip Serhii](/t5/user/viewprofilepage/user-id/5084954) manually choose every field to copy, so I started thinking about whether I could "clone" an issue by pulling the data from an API call to get all the field data in JSON format and then just plopping that into **Additional fields** in the **Create action** and lo and behold... it works (even though the rule complains about invalid JSON).

([@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313) you might get a kick out of this)

Here's what that looks like:

![Screen Shot 2022-12-07 at 11.12.39 PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/229542i0FDA0A3D37448977/image-size/large?v=v2&px=999 "Screen Shot 2022-12-07 at 11.12.39 PM.png")![Screen Shot 2022-12-07 at 11.13.12 PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/229541i5D79B7329D33045A/image-size/large?v=v2&px=999 "Screen Shot 2022-12-07 at 11.13.12 PM.png")

For information on what this API Web Request is about, and how to generate your own Authorization Header, take a look here at this article:

* [Automation for Jira - Send web request using Jira REST API](https://community.atlassian.com/t5/Jira-articles/Automation-for-Jira-Send-web-request-using-Jira-REST-API/ba-p/1443828)

To explain a bit more about what I'm doing, I'm using Automation to make a call to Jira's REST API, which conveniently returns values for every field for the issue I request (BT-1), in a format (JSON) that can then be plopped right into the Automation's **Create** action's **Additional fields**.

comments: author: Bill Sheboy
body: Hey, [@Darryl Lee](/t5/user/viewprofilepage/user-id/1365322)

That's quite clever, and...how many of the fields did you check?

I wonder about fields which are either not supported in the REST API or which have some typing issues between get/write motion. I suppose this could be validated by comparing the new issue's JSON with the source (outside a rule or inside).

Thanks, and best regards,  
Bill


author: Darryl Lee
body: Who me, validate my rule? Haha. :-}

OOOF, I realize now that I don't think my hack was actually working, or at least not fully. The other rule was still running. ODDLY though, for a while TWO tickets were getting created for each new project. Hmmm.


author: Darryl Lee
body: Hi [@Potip Serhii](/t5/user/viewprofilepage/user-id/5084954) , as mentioned in the [documentation](http://%20https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Clone-issue), you definitely can:
> Creates a duplicate of an issue within the same project **or a project of your choosing.**

I'm going to guess that if you don't see the option to choose another project to clone from, then your Rule is probably scoped to a single project. You can change this from Single to Multiple or All projects in the Details for your rule, as described here:

<https://support.atlassian.com/cloud-automation/docs/create-and-edit-jira-automation-rules/>

The Scope option looks like this:

![Screen Shot 2022-11-25 at 10.53.40 PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/227640i4C9D2D29009D82C8/image-dimensions/455x264?v=v2 "Screen Shot 2022-11-25 at 10.53.40 PM.png")

comments: author: Potip Serhii
body: Thank you very much for your answer, here is what I do: <https://www.screencast.com/t/0yOuL7mGj8a>  
1. I create a project  
2. I check that I am creating the project  
3. I find a task1 in a pre-created project  
Now I need to clone the found task1 into the created project, I don't understand how to do it.


author: Darryl Lee
body: Thanks for the screenshot!

So is Author the same as Initiator? I assume so.

So I think you won't be able to use the actual **Clone Action** because that always uses the "current issue" as the source of the clone.

But what I think you \*should\* be able to do is **Create a new issue** in the new project with the looked up data. To avoid any problems (like finding multiple issues with the same summary), I would specify an exact issue for your JQL lookup, like so:

```
issue = BT-1
```

Then it's just a matter of Creating the issues with all of the fields set, or probably just the fields you care about, populating them with the corresponding fields from the issue you looked up, using the [{{lookupIssues}}](https://support.atlassian.com/cloud-automation/docs/jira-automation-actions/#Lookup-issues) smart value. Since searching for an exact issue should only return one result, we can use [{{lookupIssues.first}}](https://support.atlassian.com/cloud-automation/docs/jira-smart-values-lists/#list.first) to retrieve field values from the first (and only) issue.

This would look something like this:

![Screen Shot 2022-12-07 at 10.32.31 PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/229539i8EDBA09B30D07E31/image-size/large?v=v2&px=999 "Screen Shot 2022-12-07 at 10.32.31 PM.png")

NOTE, I was unable to to save my test rule when I tried to include a check for Initiator (Author).

![Screen Shot 2022-12-07 at 10.18.54 PM.png](https://community.atlassian.com/t5/image/serverpage/image-id/229538iDE4311200E784205/image-size/large?v=v2&px=999 "Screen Shot 2022-12-07 at 10.18.54 PM.png")

So I had to do that check on {{project.lead.displayName}} which isn't *great* , but the {{project}} Smart Value does **not**appear to include information on who created a project.


author: Darryl Lee
body: Hi - I saw you were having some problems.

Hm now that I know what your trying to do, maybe change the Scope back to All or maybe Projects of specified type (Software development)?


author: Potip Serhii
body: Hi - Here are the current settings:  
Scope and Project created  
<https://www.screencast.com/t/JVgib1u6qmTN>  
log  
<https://www.screencast.com/t/1cHpDm9kw9h5>


author: Darryl Lee
body: Thanks - yeah, configuration looks right to me.

I have not seen that error before about "Could not find create meta data for project/typeId", but it looks like others have seen it:  
<https://community.atlassian.com/t5/Jira-Software-questions/Simply-automation-error/qaq-p/1458621>  

I guess you might try [@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313)'s suggestion from there:
> I have worked around this condition before by putting a Re-fetch action immediately after the trigger. That will make the rule run a bit slower, and it will confirm the issue is fully loaded before accessing the fields.

Hopefully this works for you!


author: Potip Serhii
body: Thank you for your help, I tried Re-fetch in different areas to insert everywhere, it gives an error <https://www.screencast.com/t/Ie6hQKIq6>


author: Bill Sheboy
body: Hi [@Potip Serhii](/t5/user/viewprofilepage/user-id/5084954)

In the audit log details, to which action in the rule is that error associated? If it is an Issue Create or Edit, perhaps that error could happen when...

* team-managed projects are involved and the issue types and custom fields are different
* the target project for the issue change does not have the fields associated, or available on the edit view
* there is a permissions issue for the person triggering the rule relative to the target project

Kind regards,  
Bill


author: Potip Serhii
body: Hi [@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313)

Created 2 test projects managed by the team, issue types and custom fields are the same <https://www.screencast.com/t/Qm8LKmxj9dC1>, <https://www.screencast.com/t/KO8NoGcv5s>  
I run the rule with administrator rights.

I don't see any activity in the audit log because I can't save the rule due to an error.


author: Darryl Lee
body: Ah yeah, so Team-managed Projects are... different. I just did a little test, creating a few of them, and what's happening is, even though the Issue Type looks like the same "Task" as any other project, in Team-managed Projects, they are actually all uniquely different issue types.

SO THAT is what this error is about:

```
Could not find create meta data for project/typeId -
10037/10002
```

There's a tiny bit of documentation about this [here](https://support.atlassian.com/jira-service-management-cloud/docs/issue-and-request-types-in-classic-and-next-gen-projects/), although it doesn't get into the underlying problem: In Automation we're asking to create a new "Task" associated with a new project. Because the project has not yet been created, it assumes you mean a Company-managed Task of type **10002.** But in the two Team-managed projects I created, when I look at the Task Issue Types configuration, the URL shows issue type IDs that are unique (Example: <https://MYSITE.atlassian.net/jira/core/projects/MYPROJECT/settings/issuetypes/>**10025**)

SO THEN, the root problem here is that this won't work with Team-managed Projects because global issue types are unavailable there. Here's a question asking about this when Team-managed projects were still known as "Next-Gen": [Create 'global' issue type for all next-gen projects](https://community.atlassian.com/t5/Jira-Software-questions/Create-global-issue-type-for-all-next-gen-projects/qaq-p/1322590)

On a related note (Team-managed projects being different from Company-managed), as [@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313) alluded to, even if we were able to figure out the Issue Type problem, you might also have issues with Custom Fields, because while they *look* the same, they are actually **different fields**, per this announcement announcing that they're eventually going to make them shared:

* [Announcing the ability to re-use global custom fields in team-managed projects](https://community.atlassian.com/t5/Jira-Cloud-Admins-articles/Announcing-the-ability-to-re-use-global-custom-fields-in-team/ba-p/2209113)

++**CONCLUSION**++ {#toc-hId--499193676}
----------------------------------------

Since it sounds like you are the one creating projects and wanting them to have consistent fields, initial tasks, etc. I highly recommend using Company-managed projects instead of Team-managed. It would allow you to ensure consistency across projects, and it would let this rule work. :-}


author: Potip Serhii
body: [@Darryl Lee](/t5/user/viewprofilepage/user-id/1365322) [@Bill Sheboy](/t5/user/viewprofilepage/user-id/1685313)

Thank you very much for the detailed explanation


Tags: cloud