I have Project-A, can I use it as a template to copy for other new Project?

[Kristy]

my requirement is: I want to save a standard Project template including it's settings(workflow, issuetype, issue fields,permissions, etc) and issues(I don't need to create new issues with same contents in a new project). When create many new projects, people can only revise the content if needed or add new issues or create sub-issues or delete issues if necessary.

Is there a way to make it happen.

[Gor Greyan]

Hi @Kristy

Welcome to the Atlassian Community!

Yes, this is possible in Jira Data Center, but it depends on what you want to copy.

If you're only looking to reuse the project configuration (workflows, issue types, screens, permission schemes, notification schemes) you can create a new project and associate it with the same schemes used by Project-A.

If you also want the new project to include a set of template issues, epics, tasks, and subtasks that users can modify after creation, Jira doesn't provide this functionality out of the box. In that case, many organizations use Marketplace apps.

Out of curiosity, do you want every new project to start with the same set of template issues, or are you mainly looking to reuse the project configuration?

[Kristy]

currently I found a way, I am not sure if there are other more easier way.

1. when create a new project, I can select 'create with shared configuration' to copy the template project's settings.

2. I can use Bulk Clone to copy all issues from template project.

yes, i want every new project to start with the same template including the issue. 

[Gor Greyan]

Dear @Kristy

Happy that you could achieve it.

Also, as far as I'm aware, Jira doesn't provide a native one-step option to create a new project that includes both the project configuration and a predefined set of template issues.

[Kristy]

i think only plugin can provide one-step option.

for the bulk clone, it also has limitation. I want to copy saga-epic to new project, but it can not keep the parent link connection to the new cloned ones, or the epic is still linked with old saga, i have to manually reselect the parent link.

[Gor Greyan]

@Kristy

You're correct. That's a limitation of Bulk Clone. The issue hierarchy isn't fully remapped when cloning into a new project, which is why the parent link must be updated manually.

[Trudy P Claspill]

Hello @Kristy 

Welcome to the Atlassian community.

Adding to what the others have said, you could consider setting up Automation Rules to clone the issues after the project is created.

Automation Rules cannot clone the entire issue hierarchy in one rule and maintain the parent/child links. You have do use multiple rules and do something like this:

Rule #1: clones issues at top of hierarchy

- Trigger the rule manually (because Jira DC doesn't have a trigger to detect that a new project has been created)

- Use a Branch: JQL to select the issues at the top level of hierarchy in the original project.

- Clone them into the new project

-- As you clone each one add to the new issue a Label to indicate you will need to look at it in the second rule to clone its children

-- As you clone each one add to the new issue the key of the original issue.

Rule #2: detect an issue created by Rule #1 and clone its children

-- Set this rule to be able to be triggered by the actions of another rule.

- Trigger the rule by issue created

- Add conditions to check for the issue type and the Label you added in Rule #1

- Use a Branch: JQL to select the child issues of the original issue (whose key you recorded in the cloned issue.

- Clone each child issue into the new project

-- As you clone each one add to the new issue a Label to indicate you will need to look at it in the third rule to clone its children

-- As you clone each one add to the new issue the key of the original issue.

Create additional rules like rule #2 to cover each level of the hierarchy.

I've seen this methodology used in Jira Cloud. I have not recreated it myself in a Jira Data Center environment.

[Gabriela]

There are really two separate things tangled together in what you're after, and Jira treats them very differently: the project's configuration, and the issues that live inside it.

The configuration side is native. When you create a new company-managed project there's a "Share settings with an existing project" option — point it at Project-A and the new project starts life with the same workflows, issue types, screens, fields, and permission/notification schemes. Three things to know before you rely on it: it's company-managed only (team-managed projects can't share settings), only a Jira admin can create a project this way, and it isn't offered on the Free plan. The one that trips people up is that "share" is literal — the projects point at the same schemes, they're not independent copies. Edit a shared workflow later and it changes for every project sharing it. If you want each project to be able to diverge on its own, you'd copy the schemes rather than share them, or share the setup and only branch the pieces that genuinely need to differ.

The issues are the harder half, because there's no native "clone this project with its issues" button. The usual pattern is to keep Project-A as a master template and copy its issues into each new project as you create it. Two realistic ways to do that: export Project-A's issues to CSV and re-import them into the new project — free, but it won't carry attachments, comments or issue links and you'll remap a couple of fields on the way in — or use a copy/clone app from the Marketplace, where Deep Clone for Jira and Elements Copy & Sync are the two most teams end up on; those bring the whole hierarchy, attachments and links across in one shot. Automation can also clone issues into another project on a trigger, with the same caveat that it skips attachments, links and comments.

So the short of it: reusing the setup is a built-in checkbox, seeding each project with the same starter issues isn't, and whether the app route earns its place comes down to whether those attachments and links matter to your template.

One thing that'd help me point you at the cleanest path — are you on Cloud or Data Center, and roughly how many template issues are we talking about per project?

[Trudy P Claspill]

@Gabriela 

Just a point of clarification:

In your response you talk about Company-managed and Team-managed projects and end asking if the user is using Cloud or Data Center. The tags on their post indicate they are using Data Center.

[Gabriela]

@Trudy P Claspill good catch, thanks - the tags do say Data Center, so scratch the Cloud/DC question. On DC the config side is "Create with shared configuration" rather than the company-managed share I described. The issue-copy gap is the same though: a clone leaves Epic Link pointing at the original epic, which is what JSWSERVER-7721 tracks, and a Bulk Change on that leftover value re-points them in one pass per epic.