The problem with the options listed for add-ons is that none are available for the Cloud offering. Cloud users also need the ability to copy or clone projects so we do not have to reconfigure the project each time one is created.

+1 to previous comments.

+1 to Chantale's comment. The implementation is a welcomed step in the right direction, but only partially provides a 'workaround'. This offering doesn't even create boards as they exist in the 'Create from shared configuration' copied project, plus all that was mentioned in Chantale's comments.

Only very partially. It is a proper workaround I suppose but the bigger the team the riskier it is. Say I make a base project that all software development project should start from. One may think it's simply a standard project and modify it which means that the next time we will want to add a project our base is destroyed. If it was a project template it would be clearer what the intent is and I would presume only JIRA administrators with global permissions could modify it. Also, the access to a project template is clearer. It does not require specific training as how and when to use and for which project kind.

So yes partially fixed but the custom project template would be better and easier and have faster access.

Isn't this partially fixed with "Create from shared configuration" since Jira 7?

this feature would be great to sync configuration between a test instance and a production instance

I would just like to re-iterate my company's wish for this feature. I know that the top comment names four plugins that can be used for this purpose, however due to the inactivity on this issue these plugins have become increasingly more expensive - in fact the one we use recently increased its price by SEVEN fold. We would like to use JIRA more widely in the company and start using Ondemand instances as well, but this issue more than any other is holding us back.

With the new "Project Types" introduced in JIRA 7.0, may I suggest the time is ripe to introduce Project Templates in 7.1.

Edit: Incidentally we are now proceeding with a workaround as follows; We will stop using our current plugin (too expensive) and create a template project with all roles removed except for our project creators in the Manager role. Thus our regular users should not see the template project(s). It does mean that our project creators will still need an explicit work instruction to use the small "Create with shared configuration" hyperlink provided in JIRA 7, to select the correct template project, and to re-add the roles they desire to the project, and they will need to be careful not to modify the template project by mistake. While not ideal this is still more manageable than training them to select every scheme correctly by hand.

You have a point. However we deployed our JIRA as a Service so our users can create projects theirselves without any help from our team (We already have 1,200 JIRA Projects, 21,000 users and still growing) so this feature is nice to have.

Right now, we have a front end portal that let our users create their JIRA Projects with "template choices" on it (SDLC Template, Agile Template, CI Project, etc...) to give them this feature.

While it's an inconvenience, I've found that (as long as you have the 'Jira Default Schemes' reenabled) you can create a new project then assign all the correct schemes in around 5mins. Which isn't an unreasonable amount of time to create a new project. Given the customisation involved (new key, avatar, URL) a template engine would probably only save 3-4mins for each project, which for our company would be ~30-60mins per year. Small change in the grand scheme of things...

I'm another user that loves most of JIRA (Cloud), but everyone in my team hates that copying/cloning projects isn't a standard feature as well. I use Bitbucket for repositories; not exactly sure why you can't do something similar to their repository cloning and simply rename it.

We're still evaluating JIRA, and this issue alone has the potential to skip JIRA altogether. Is there really no other solution other than Script Runner that's developed in the past few months?

@Dmitry, the way I've achieved this in my Cloud instance is by requesting the setting be reverted by the Atlassian support team (as mentioned in CLOUD-7806 / JRA-43415). I now have the normal create options which includes the 'Jira Default Schemes' option which uses the schemes I already have defined.

You can also use Bob Swift add-ons to automate the process:

• Use the JIRA Command Line Interface (CLI) add-on as shown in this recipe to copy the project. (This works for JIRA Server and JIRA Cloud)
• You can further refine the technique to allow end-users to create templatized JIRA projects by using the Run Self-Service Reports for Confluence add-on to build a form through which users can select which "template" on which to base their new project, similar to how these recipes demonstrate. (This works for Confluence Server.)

For us (download version of JIRA), the workaround that speeds up things a lot, is this one:

• create a template project - with settings as you wish, such a the schemes of your preference, etc., probably with empty Roles, since those are being taken care of within the project. Perhaps also create multiple templates (eg, we have one for bug tracking and one of Agile dev). Also, probably the template project lead will be yourself.
• install Script Runner plugin, create a bookmark (eg in your browser) to the Copy Project function of the plugin.
• any time a new project is needed, click the bookmark = go to the Copy Project page, select the template, fill in new Key and Project name, Run....
• finally, change the project lead to the real one and off the project goes.

Since this seems so simple and a huge improvement, also I'm one of probably many wondering why this isn't a standard possibility in JIRA.

@andrew so is there a way to create a project without any duplicate rubbish?

@Andrew Good to know, thanks!

@Dmitry Pashkevich, sorry to confirm but the 'Software Development' also creates rubbish throughout the system instead of using the preconfigured defaults. From what I can see CLOUD-7806 covers bringing the 'Classic Workflow' back for OD instances by logging a request with the Atlassian support team.

I think the Classic Workflow has been renamed to Software Development

@James, that is a good suggestion, and would help a lot.

Unfortunately, I do not see that option

@James Seddon - I use simple issue tracking for the same reason. If I'm going to have to go through and set a scheme for every category, at least it can be super clean until I do - and VERY obvious if I miss one.

@anyonefromAtlassian - is this not supported because of the assumption that projects shouldn't be created very often? I typically make a new project for each discrete effort - New Feature Launch, Rework of that feature's UI, Integrate cool third party functionality into new feature (better names of course) and we archive the projects out after they're done. It gives us a very clean view into scope and creep, as well as a sense of project completion rather than large, never ending backlogs.

@Paul Draper - I'm not defending Atlassian by any means... I want this just as much as you do. But what might help you a little bit. When I have to create a new project I create it as a "Jira Classic" project. This doesn't create the garbage that needs to be cleaned up after the fact. All you have to do is switch things over to the schemes you want to use. I know it's not the ideal situation, but this might save you a little time in having to clean up the mess Jira makes each time.

I don't even care if there are "schemes" or "templates".

I would just like to be able to copy a project.

Currently, I create a new one, and spending an hour trying to get it looking like the other ones, and deleting the automatically generated garbage schemes and such.

@Ming Hao: a good place to go would then be https://answers.atlassian.com/ . There are friendly people who will help you out if you have a question. In addition there is a Jira administration tutorial series on youtube, that might be of help as well: https://www.youtube.com/watch?v=V7NXmFqgPBo and last not least there are probably some people in your area who offer consulting or Jira workshops for some money.

But if you want help, this issue tracker is not the right place to go. It is just a place for users to suggest concrete things they would like to see implemented in Atlassian tools.

I do not want new workflow scheme created each time a project is created.
I'd like some help to simplify project creation.
Is it possible due to everyone is an admin right now in our account?
I'd appreciate some help instead me trying to figure out JIRA on my own.
I have a support ticket open with JIRA after much self learning period, seems wasted.
I'd appreciate some help offered from JIRA folks.

Thank you

Why would you want a new workflow scheme created with each project? That seems very wasteful. It sounds like you might not fully understand how schemes work?

When a Project being created, a "NEW" WORKFLOW SCHEME would be created automatically. We would like to be able to streamline Project creation without configuration scheme for each and every Project we create. We only have JIRA Cloud for our organization's usage of JIRA and we are considering abandon JIRA for some other platform. We would like more help.

With the addition of the six "Project Types" when you create a new Project, I'm really hoping to see the ability to add our own type.

It's very cumbersome to have to move through each section of the administration pane selecting our custom scheme every time we make a new project. It's the same choices every time and handling it by selecting our own "Project Type" would be very helpful.

This issue was created 10 years ago. For what seems to be a very useful feature that many people are shouting about, why hasn't there been any movement on it?
We use OnDemand/JIRA Cloud, so none of the add-ons work for us. Having a 'Copy Project' OR Project Schemes (selectable at 'Create Project' stage) would save lots of time.

Here is an idea to improve Jens' cloning idea of making an Excel export, enhancing the output in Excel and then importing the enhanced data with the CSV importer.

Better Excel Plugin can save you most (all) of the manual issue data enhancement work, as it allows creating intelligent Excel exports with Excel functions, formulas and all the other native features. For instance, if you needed to do some manual string replacements before importing the reworked issue data into your new project, you can now just use Excel's string functions to do that automatically for you. Do you want to derive a field from some others? Use a formula. Do you want to initialize a field to a static value? Use a hardcoded value in your export template.

It will save a lot of time if you create new projects frequently.

It's pretty obvious that Atlassian will not address half-done or missing features in their products. You shouldn't even expect these being addressed. From their point of view: adding a more elaborate project scheme manager/freely adjustable Agile tool/Confluence content editor that works is simply not a selling point. Adding new features which have no purpose like shiny new ADG, task management in Confluence is something they can put on their website's what's new section. Most voted features which would fill a hole people walk in every day? Why? We can't sell it for just being good.

What have we learned from it: if you see a marketing manager or a guy which looks like a marketing manager, start running in the opposite direction. They ruin whatever they touch.

As said before. What about On-demand?

Can't be leave such an important feature is taken so lightly. Don't think it would be that hard to implement either, at least not a simple version.

I have to say I do too.

This is the first of a couple of really quite major gaps in the on-demand functionality that we've discovered in the first few weeks of using JIRA - I'm rather taken aback at the lack of effort that Atlassian are seeming to spend on these.

Doesn't bode well for our continued usage of JIRA; it's hard enough getting people to change their working habits even when every change is a benefit, as soon as there are changes that need to be made to work around shortcomings (and obvious ones at that) in the new system then you really do face an uphill struggle.

"The initial focus if this project will be on permissions and improvements in the most often executed actions"
I am unsure about other admins usages, but one of my most often executed actions is creating a new project that adheres to our standards.

@shapeshop: requests with third-party solutions are naturally less likely to be implented. Probably since a) there is already a workaround and b) if they implement a lot of features that plugin vedors are selling, Atlassian might ruin their plugin vendor market. Or they'd have to buy the invention, which in unlikely to be cheap.

I agree with Shapeshop.

This should be core functionality rather than dodgy add-on functionality. Why do I feel we are being short changed on this?
So, you suggest we all go out and pay extra for add-ons that may or may not do the job and may or may not be adequatley supported. some of these add-ons are one version wonders which are not maintained well or, in some cases, by more than one student hoping to make it big with little consideration for the basics of configuration management or the end customer.

Not really what we are after here. If the atlassian way is palm us off to third party software then then the customer may start to look at third party for the core solution too.

So thanks for dismissing the request despite being voted for by 365 users.

Do not patronise us by thanking us for our patience we are actually paying customers.

Would like to second the above comment. We are on OnDemand and the lack of project schemes/templates causes us issues every day. A real solution to this issue for cloud users is sorely needed.

Not a single one of the "solutions" mentioned above works with On Demand / Cloud instances. Come on Atlassian, why are you leaving those of us who give you the most money hanging in the dark without a solution to this problem.... and it is a big problem.

Would just like to add my comments to this - I would like to be able to create a new project scheme so that I can allow my users to select a specific type of project which automatically has the correct issue types, screens and workflows without having to manually update the project after creation.

I need this today

Ditto to the above

Can't believe this has taken so long. I feel for all the people who have been setting up projects manually for 8+ years while waiting for this fix.

If it is not going to happen soon, I wonder if Atlassian would consider an (optional) advanced Create Project screen with drop-down boxes for Issue Type/Workflow/Permissions/etc. schemes so we can set them all on the one screen while creating a project, instead of having to visit dozens of screens to get everything going.

I actually want Sprint Templates. I use Jira for Monthly, repeating sprints, and I also have a standard on-boarding story set that I want to clone into new projects as a group.

We have a separate JIRA Project for each external client that we support. We went this route mainly so it is very easy to prevent clients from gaining access to other clients software development information. However, the SDLCs and workflows for each client are nearly identical. Therefore having a project template would greatly improve project creation efficiency. For now, we found an Add-in work-around - https://marketplace.atlassian.com/plugins/com.wittified.jira.project-creator. However, this requires yet another license when it should be part of the base JIRA platform. By adding a project scheme or template to the base JIRA platform, JIRA will become that much more attractive to companies who want to rapidly grow their client base through collaborative software development relationships.

In this context it would be as well good to get a possibility to deploy such a project schema from one environment to another isolated from the data.
This is needed if you have a real test environment you want to perform your configurations on and than apply and deploy it to production.
I was really suprised that such a possibility does not exists which force you to do most things in production. (live system) or you have to do the configs twice.

would also be useful if the copy project automatically created a new context for custom fields.
Please make this easy!

This is yet another functionality that should be connected to project categories.

When creating a new project and selecting project type in Jira6+, it should allow me configure how that project type is configured, or create my own type!

Thanks,
Aviva

@Paul Harvey - we use Script Runner to clone projects successfully (https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner). You can select what elements of a project you want to copy. The only things that aren't copied are worklogs.

Need to clone projects.

@Yves Schuhler: Yes you are right, the plugin is only available for non OnDemand. Hopefully a way can be found to make the plugin available for "OnDemand" user in the future...

@Jean-François Thibeault : thank you very much for your answer. Again, this solution is only available for non "OnDemand" instances. I hope this plugin will be ported soon for OnDemand !

Another solution to this is to use Gaia for JIRA (see https://marketplace.atlassian.com/plugins/ca.nuum.gaia)

This plugin will let you create JIRA project templates that include things like scheme configuration, predefined content (issues, tasks, etc.), filters, dashboards, etc. from which you will be able to create pre-configured and pre-populated projects.

You can even associate a template Confluence Space (also with predefined content) that will be automatically created alongside your JIRA Project.

tj5, thanks for your comment.

Let me explain. The reason why most of JIRA plugins are not available for OnDemand deployments is related to the way the original plugin architecture was designed. While being extremely powerful it actually allows plugins to integrate with JIRA in a really low level and as a consequence a potentially faulty plugin could bring many instances down. Therefore around a year ago Atlassian decided to create a new addon architecture allowing the addons to work in parallel to JIRA and thus be safe to deploy and run. This new architecture is called "Atlassian Connect" and we are getting close to releasing the 1.0 version of it.

Please read more here.

The main takeaway for you is that in near future you will observe a large amount of addons being developed (or ported) to Atlassian Connect platform and made available for OnDemand instances of JIRA.

Thanks for the update on this issue.

For anyone finding this while searching for a solution to this problem, you might consider hosting JIRA on your own. We're finding after roughly 6 months of using it that On Demand is extremely limiting. There are free solutions available to solve this problem (and many others), like this one pointed out above if you host your own instance:

[Script Runner's 'Copy Project' | https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner\] function copies all of following from source project:

• All Schemes (Issue Types, Workflows, Screens, Fields, Permissions, Notifications)
• Role memberships
• Custom field configurations
  Plus Project Template Options to copy each of the following:
• Components with associated component leads and default assignees
• Filters and Dashboards beginning with the project key
• Versions with descriptions, start, and release dates
• All issues from the source project including:
  • Sub-tasks with assignees pre-set
  • Issue notes/comments
  • Attachments

Still not sure why Atlassian does not allow access to this FREE plugin in OnDemand instances ... but then again, I don't understand much of Atlassian's business choices.

We're a creative agency that does website work (tied in with BitBucket) as well as purely creative jobs. We therefore have defined a few project "types" with their own schemes and it's a major hassle for our "less technically oriented" Jira admins to remember to update schemes etc after creating a project. I'm very surprised that this (as well as a few other features) is not part of Jira as standard.
Apart from that we're loving most of the rest of Jira.

was this issue really created in 2005 with no progress made 8 years later?

Hi,

We have just released a new add-on that provides you with the ability to create a project snapshot (including all dependent objects like workflows, schemes, etc.) and apply it to another project - even in another JIRA instance.

You can check it out at the Atlassian Marketplace: https://marketplace.atlassian.com/plugins/com.botronsoft.jira.configurationmanager.

Martin, I think your best available solution is to script the project creation with Jira CLI (Command Line Interface). The CLI allows you to clone or create new projects and to copy or create new issues. Best option will depend on your needs.

See https://answers.atlassian.com/questions/207585/clone-project-with-jira-command-line-interface

Have Atlassian indicated anything about when we can expect this?

I can't find anything telling me their opinion on it. It is a real drama for us. We have projects starting every week which have a list of 30-40 standard tasks. This is horrendous to do manually....

That's EXACTLY what we need, Michelle!

And I think what the 200+ people who've voted for this issue, as well as creating similar / duplicate issues over the years have asked for.

Thank you for clarifying it so well.

My vote is for a complete Project Template Clone with all the must have time-saving options that Jamie Echlin's 'copy project' function does in his 'script runner' plugin (free for Standalone installations).

Please Atlassian implement this part of 'Script Runners' plugin into OnDemand for free! A full featured template system is imperative for efficient management of our rapidly growing global organization. It wastes far too much Administrator time to manually recreate the same settings along with all templated issues with sub-tasks for every new project.

Script Runner's 'Copy Project' function copies all of following from source project:

• All Schemes (Issue Types, Workflows, Screens, Fields, Permissions, Notifications)
• Role memberships
• Custom field configurations

Plus Project Template Options to copy each of the following:

• Components with associated component leads and default assignees
• Filters and Dashboards beginning with the project key
• Versions with descriptions, start, and release dates

• All issues from the source project including:
  • Sub-tasks with assignees pre-set
  • Issue notes/comments
  • Attachments

The technology already exists with Script Runner. What are you waiting for?

The lack of this functionality is the main reason we can not convert other large departments within our organization to JIRA. They are looking at your competitors which means our entire company will likely migrate to a system that does include this out of the box! (Easily a loss of over $1000/month for Atlassian.)

It seems that the scope of this feature request deals with the 'structural' part of a project, and copying / cloning only that part, if I understand what I've read above.

However, I came across this issue by following a 'Clone Project' issue that was linked to it.

Our need is to be able to fully clone or copy a project, including all of the issues that might be in it, to save us the time it takes to repeatedly set up the same tasks for every new project of the same type that we do for new clients.

Is this the correct issue to put my vote on for cloning a project fully, including all of the issues that it contains - or more preferably, setting up a 'project template' for the same purpose?

I too have voted, and +1 Alan's request above! We also work in a project-centric environment, and the project creation process currently is long-winded, and error-prone.

I would like to add my vote for implementing this feature, for reasons already mentioned: creating a project with custom subsystems is not a lightweight operation, and I work in a project-centric and project-heavy environment. The work required in JIRA to create [custom] projects is out of alignment with the ease and speed at which the other internal systems around JIRA create projects. There is a bottleneck here.

paperwork isn't profitable-or in JIRA's case-clickfests are not profitable.

I appreciate your attention and thank you for the opportunity to use JIRA.

Please, Please, Please add this functionality to OnDemand!

I'm using the Import Wizard, which allows you in step 3 (I think) to map the csv columns to fields in your Jira instance. So you could run an export via the issue filter and then use the format created the by export.

A sample wouldn't do you much good as we have quite a few custom fields.

Hope that helps

Jens

Jens,

I've got a standalone (v. 5.1) with tons of projects and users, groups, and workflows already set-up. Later, my company chose to go with OnDemand, but since I have no access to upgrade our standalone to the current OnDemand version, I can not import any of this info to OnDemand. Your workaround sounds like a way to get at least some of the project settings transferred.

Thanks so much! This was very helpful info as a workaround until Atlassian builds this feature (better than starting from scratch every time). Do you have an example .csv you could include with example issues?

Also, does this pull in all the components/assignees, roles, project lead, and project schemes?

Just to share a pretty ugly yet fairly efficient work around:

1. Create a (temporary) filter in JIRA to capture all issue you'd need for the Project template from an existing project and Export into Excel with all fields enabled.
2. Manipulate the issues in Excel to your heart’s content, which is A LOT easier than creating issues one by one in JIRA
3. Save as csv, and keep them for reuse in central place (e.g., Confluence)
4. Import the csv using the JIRA Project Import
5. Follow the wizard and save the configuration after you are done for reuse (that way you don't have to configure the mapping again)

This gets you about 80% there. Some fields may not get filled to your needs. E.g., I noticed that the Account field from TEMPO cannot be imported because it uses a custom format. (only a problem if you use TEMPO )
Those things can easily be fixed with the bulk change feature.

Cuts down my project setup for project with 300 standard issues to less than an hour. Of course, it helps to work with naming conventions etc. to enable efficient bulk editing.

Now, Atlassian, don't get any ideas - Project Templates and Component Templates are still desperately needed. You guys just have been very persistent on insisting on your way as the only way of working with your tool

Our company desperately needs this for OnDemand as we need to create new projects regularly. A template cloning feature would save a ton of time as the system admin.

VERY much appreciated for Jira OnDemand!

More importantly, is this plug in available on the OnDemand platform? I'm afraid, I know the answer to this question

Until Atlassian deems this problem worthy of their attention, I'm afraid we are stuck with manual copy & paste.

Just JIRA 6

Pawel, does your plugin work on Jira 5, or just Jira 6?

Just to let you know I created a plugin that may help in your case - https://marketplace.atlassian.com/plugins/com.atlassian.jira.plugins.jira-clone-project-plugin.

It allows you to create a project based on an existing project - it will copy versions, components, scheme settings (not the schemes actually) and roles. It will also extend custom fields' scopes. So basically creates a clone which you can then customize.

Would this Plugin be available in the OnDemand platform? There are a few plugins that make project management with Jira easier, none of which is available on the OnDemand platform.

Please take a look at this plugin: https://marketplace.atlassian.com/plugins/com.wittified.jira.project-creator
Project Creator for JIRA allows the JIRA administrator to set up project templates and assign specific groups the permission to create new projects from these pre-defined templates. Project creation is super simple with it if I may say so myself

How is the status of this issue?
It would be nice to see jira handle copy project tasks (inlcuding copy all configuration, schemes, screens ...) without the need of external plugins.

I would definitely like to see this feature added. We run a ecommerce development agency and run our design and builds using a customised workflow and notification scheme which is the same for all our projects so having the ability to clone a template or set a defined workflow as default would be the best!!

Thanks

We have developed a Jira Plugin for this functionality and have shared it as Open Source for external contribution.

You can find it on the Atlassian Marketplace here:

https://marketplace.atlassian.com/plugins/com.topmanage.jiraplugins

Here is my business case:

I have a client who wants to have a Jira project per client. This is needed because each client has multiple users who all need to be able to see each others' tickets, but not tickets from other clients. So I could not solve things using a Reporter Only permission scheme or a manageable Issue Security setup. Instead they want to create a new project with visibility to one client's users only. In creating a new project they have to select:

• Permission Scheme
• Notification Scheme
• Workflow Scheme
• Field Config Scheme

etc. the only differences are Project Name/Key and the members of the Project Roles. They'd like to make this take as few steps as possible.

Also, if anyone knows a better way to achieve the visibility needs, I would not need the copy project feature added.

>My recommendation at the moment is to investigate using the Groovy Script Runner from Jamie Echlin. >This plugin comes with a "copy project" script that uses all the same schemes as the template >project. For bulk cloning of a set of issues I'd look at modifying the create and link example.

So how can one convince Atlassian to make a scripting environment available on the On Demand platform? I sure they will be thrilled when I start running scripts in an SLA controlled environment :-p

This is the double wammy here for us, since all the workarounds don't work in the OnDemand environment.

Anyone from Atlassian cares to comment?

>Also, what is the point of having Project Categories in the first place if it only organizes the projects into groups on ONE page in JIRA? I could easily accomplish the same task by
>changing the display names of all projects in one group and prefixing it with the same word. Without Project Schemes, Project Categories are, for lack of a better term, worthless.

Anæmic yes, but not worthless. The Projects gadget lets you display just one or two categories. Newer versions of JIRA have a Category JQL keyword for searching only for issues in projects in certain project categories. But definitely not the top-level grouping that many JIRA administrators expect it to be.

To add to what Matt said above, in recent versions of the script runner plugin, the copy project function will also copy all issues within the project (if desired), including any attachments they may have.

But as Adam says, bulk changing the workflow scheme is a major PITA, although that is the only "scheme" change that is tricky to automate.

Unfortunately, cloning of projects does not solve all the problems that project schemes would solve. Sure, if your company creates new Projects on a daily basis, this is helpful. However, when needing to change a workflow which requires you to clone the workflow in order to make the appropriate changes, cloning a project does not solve this. How are you supposed to update 30 projects which all use the same workflow with the new Workflow scheme which you are forced to create? This requires an absurd amount of mouse clicks to change the workflow scheme on one project, then multiply that by the number of projects you need to change. It could become a day or week long endeavor.

The act of changing multiple projects all at the same time is where Project Schemes would ultimately save time and effort.

Also, what is the point of having Project Categories in the first place if it only organizes the projects into groups on ONE page in JIRA? I could easily accomplish the same task by changing the display names of all projects in one group and prefixing it with the same word. Without Project Schemes, Project Categories are, for lack of a better term, worthless.

Project Schemes should have been developed and deployed along with Project Categories. They should be one in the same.

The problem of making JIRA easier to administer as it scales is something I know Atlassian is aware of (see The Hundred Tab Problem).
My recommendation at the moment is to investigate using the Groovy Script Runner from Jamie Echlin. This plugin comes with a "copy project" script that uses all the same schemes as the template project. For bulk cloning of a set of issues I'd look at modifying the create and link example.

It should also be possible to use the existing SOAP (4.x) or REST (5.x) APIs to retrieve the values of each issue to be cloned and then create a new issue with the same details.

Unfortunately, the only answer I could come up with is cheap labor I created a template project with all the needed tasks and then clone them one by one.

Atlassian really leaves us out to dry here, because cloning isn't a bulk operation either. So some poor guy needs to sit there for an couple hours every month and clone close to 200 tasks, grrrh. What can be so hard introducing a project task scheme or something. There schemes for everything else, even schemes of schemes (try configuring workflows) so why are you guys so reluctant to finally provide a feature essential to a mature ALM tool. Dear Atlassian, please answer

Can anyone assist with how they get around this currently? I agree with the sentiment of the comments placed here i.e. this should be standard functionality and there has been a demand shown for many years so why is not still not available and how are people getting around this?

I want to create a new project but it will contain many tasks consistent with other projects and therefore I want to develop a number of templates which will provide a skeletal task list for each. How do others satisfy this need?

I'm agree with Jens Lippmann. We, at University of Murcia, need this feature, because all our projects have the same Issue Type Scheme, Workflow scheme, Field Configuration Scheme, Permission scheme and Notification Scheme, and we will be really happy if you implement this feature (project scheme/template).

I've found https://marketplace.atlassian.com/plugins/com.sourcesence.jira.project-template, but it works only with JIRA 3.12 and 3.13, doesn't it?

Thanks in advance and best regards.

For any ALM tool (and Jira aspires to become one it seems) this should be a standard feature in the platform. I have about 50 smaller projects starting every year with a predefined WBS. Since we are on the OnDemand platform, all the scripts and plugins are no option for us. Bulk Cloning isn't supported either, so we are stuck with manual copying. Jira is behind on this feature so please consider catching up with otherwise inferior products such as SmartBear

Just FYI, the script runner plugin can copy projects, and as of a recent version, can copy issues with their attachments (more info).

Project templates seems to be such a logical feature it strikes me as very strange it's not available (yet). We have a fairly complex and standardized process for our web projects (pharmaceutical industry) and can't create the projects from scratch every time (including project phases, milestones, etc.). We're currently evaluating JIRA and this (and the lack of custom fields on project level) are currently the top candidates for deal breakers, I'm afraid.

would like to set up a template project with appropriate permissions etc and set up a set of template issues. Then when create a new project can use the template so prpject is setup with list of standard issues.
Would be happy even with just an option to copy an issue (similar to clone but from one project to another). Then can do a bulk copy of issues from my 'template' project to my new project.

In the latest releases (I'm comparing 4.2 to 4.4 here) you cannot set the Permissions and/or notifications schemes in the Project Creation dialogue. You create the project and then go to project admin page, click on the right tab, select the permissions scheme then repeat for the Notifications and others. It's turned an operation that was documented as 'Select X from the dropdown list' in to something that needs screen-shots to illustrate properly. Great.

For some creating a new project is a very infrequent task which only happens after much preparation, and this is not an issue. But for us creating projects is something we do almost daily, we have hundreds of customers and they are used to having a new project for every task they set us, we are very agile..

Since my issues was closed as a duplicate of this issue, I'm adding my use case here. JRA-23247

When I create a new custom field, I would like to be able to a context of category. As it is, I have 15 software projects which use the same workflows and screens. I want them to remain consistent. when I make changes I have to select 15 projects, when I could pick ONE category.

Copy project in the script runner plugin works for jira 3.13-4.3.

What about JIRA 4.2?

Roberto, any chance you will update the plugin to be compatible with Jira 4.1.2?

This issue should really be thought out and fixed. It would be a great improvement. Project Schemes would add a whole new dimension to Jira.

Hi,
I've created a plugin that let you create projects from a template

http://opensource.sourcesense.com/confluence/display/JPS/Jira+Project+Template+plugin

I think this might be helpful to solve this issue.

There is now a community plugin that can copy projects.

Waow David... Too many requirements for a initially simple and efficient improvement, I would suggest to create a separate "new feature" request...

Please Mister Developers, just implement what is asked by Anton, would be already great !

A "Project Scheme" would correspond to the association of the following items:
Issue Type Scheme
Issue Type Screen Scheme
Issue Security Scheme
Field Configuration Scheme
Permission Scheme
Notification Scheme
Workflow Scheme

PROCESS RATIONALIZATION !

If the existing project setup flexibility should be kept, just give the option to select either a "Project Scheme" or a "personal configuration".

Listen to Anton wisdom !

Regards,
Ludovic

As a temporary workaround, a fairly large amount of this could be achieved by Jelly scripting. We can setup:

• Components -> Artifacts
• Versions -> Phases / Iterations
• Issues for creating an initial WBS
• Some of the project schemes, roles, default assignees etc.

Here is a quick one:

<?xml version="1.0"?>

<!-- Create Users -->
<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.enterprise.JiraTagLib">

	<jira:CreateUser username="n.dimas" password="n.dimas" confirm="n.dimas"
		fullname="Nikolaos Dimas" email="an.email@company.com"/>
		
</JiraJelly>

<!-- Create Project -->
<JiraJelly xmlns:jira="jelly:com.atlassian.jira.jelly.enterprise.JiraTagLib" xmlns:j="jelly:core">
	<j:set var="name" value="Loyalty Web Service"/>
	<j:set var="key" value="VASB"/>	
	<j:set var="lead_username" value="g.dioletis"/>
	<j:set var="lead_username_1" value="s.kladitis"/>
	<j:set var="lead_username_2" value="n.dimas"/>
	
	<jira:CreateProject key="${key}" name="${name}" description="${name}" lead="${lead_username}">
		
		<!-- Default Members for Project Roles will be setup in advance 
			 use the following command to create ad-hoc memberships -->	
	 	   <jira:AddActorsToProjectRole projectroleid="10001" actors="s.klaritis,n.dimas,g.dioletis" 
		        projectkey="${key}" actortype="atlassian-user-role-actor" />		
		
		<!-- Add Process related Components -->
		<jira:AddComponent name="P-PA" description="Process PA" componentLead="${lead_username}"/>
		<jira:AddComponent name="P-AD" description="Process AD" componentLead="${lead_username}"/>
		<jira:AddComponent name="P-NE" description="Process NE" componentLead="${lead_username}"/>
		<jira:AddComponent name="P-SE" description="Process SE" componentLead="${lead_username}"/>
		
		<!-- Select Component Assignee for explicit assignments -->
		<jira:SelectComponentAssignees project-key="${key}" componentName="P-PA" assigneeType="componentLead"/>
		<jira:SelectComponentAssignees project-key="${key}" componentName="P-AD" assigneeType="componentLead"/>
		<jira:SelectComponentAssignees project-key="${key}" componentName="P-NE" assigneeType="componentLead"/>
		<jira:SelectComponentAssignees project-key="${key}" componentName="P-SE" assigneeType="componentLead"/>

		<!-- Add Service related Components -->
		<jira:AddComponent name="C-Documentation" description="Documentation" componentLead="${lead_username_1}"/>
		<jira:AddComponent name="C-Service-A" description="Service A" componentLead="${lead_username_2}"/>
		<jira:AddComponent name="C-Service-B" description="Service B" componentLead="${lead_username_2}"/>
		
		<!-- Select Component Assignee for explicit assignments -->
		<jira:SelectComponentAssignees project-key="${key}" componentName="C-Documentation" assigneeType="unassigned"/>
		<jira:SelectComponentAssignees project-key="${key}" componentName="C-Service-A" assigneeType="projectLead"/>
		<jira:SelectComponentAssignees project-key="${key}" componentName="C-Service-Β" assigneeType="projectLead"/>
		<!-- assigneeType values:
			projectDefault
			componentLead
			projectLead
			unassigned
		-->
		
		<!-- Add Service related Versions -->
		<jira:AddVersion name="${key}.1.0"/>
		
		<!-- Add Phase / Iteration related Versions -->
		<jira:AddVersion name="INC-1"/>
		<jira:AddVersion name="ELA-1"/>
		<jira:AddVersion name="CON-1"/>
		<jira:AddVersion name="TRA-1"/>
		
		<!-- Manage Versions to set milestone (release) dates -->

		<!-- Create a template WBS -->
		<jira:CreateIssue assignee="-1" project-key="${key}" summary="Task WBS.1" issueType="Task" fixVersions="INC-1" reporter="admin" issueKeyVar="task1"/>
		<jira:CreateIssue assignee="-1" project-key="${key}" summary="Task WBS.1.1" issueType="Task" fixVersions="INC-1" reporter="admin" issueKeyVar="task1-1"/>
		<jira:CreateIssue assignee="-1" project-key="${key}" summary="Task WBS.1.2" issueType="Task" fixVersions="INC-1" reporter="admin" issueKeyVar="task1-2"/>
		
		<!-- Create issue links -->
		<jira:LinkIssue key="${task1}" linkKey="${task1-1}" linkDesc="incorporates"/>
		<jira:LinkIssue key="${task1}" linkKey="${task1-2}" linkDesc="incorporates"/>

		<!-- Create issues with custom fields -->
		<jira:CreateIssue project-key="${key}" summary="Task WBS.2" issueType="Task" fixVersions="ELA-1" issueKeyVar="task2" reporter="admin">
			<jira:AddCustomFieldValue id="customfield_10020" value="3"/>
			<jira:AddCustomFieldValue id="customfield_10021" value="2"/>
		</jira:CreateIssue>

		<!-- Create issues with custom fields -->
		<jira:CreateIssue project-key="${key}" summary="Task WBS.3" issueType="Task" fixVersions="CON-1" issueKeyVar="task3" reporter="admin">
			<jira:AddCustomFieldValue id="customfield_10020" value="3"/>
			<jira:AddCustomFieldValue id="customfield_10021" value="3"/>
		</jira:CreateIssue>

		<!-- Create issues with custom fields -->
		<jira:CreateIssue project-key="${key}" summary="Task WBS.4" issueType="Task" fixVersions="CON-1" components="C-Documentation" issueKeyVar="task4" reporter="admin">
			<jira:AddCustomFieldValue id="customfield_10020" value="2"/>
			<jira:AddCustomFieldValue id="customfield_10021" value="2"/>
		</jira:CreateIssue>	
			
			<!-- For Cascading Selects : Note also that the value for cascading selects is the optionId
			<jira:AddCustomFieldValue id="customfield_10001" value="Parent Option Id" />
			<jira:AddCustomFieldValue id="customfield_10001" value="Child Option Id" key="1" />
			-->

			<!-- For Multi Selects
			<jira:AddCustomFieldValue id="customfield_100002" value="Value 1" />
			<jira:AddCustomFieldValue id="customfield_100002" value="Value 2" />
			-->

	</jira:CreateProject>

	<!-- Modify project schemes -->
	<jira:SelectProjectScheme projectKey="${key}" permission-scheme="External Support Permission Scheme"/>
	<jira:SelectProjectScheme projectKey="${key}" issue-scheme="Support Issue Security Scheme"/>
	<!-- The following schemes should be selected manually 
		Notification Scheme: sets which events trigger email notifications
		Issue Type Scheme:
		Field Configuration Scheme:
		Issue Type Screen Scheme:
		Workflow Scheme:
	-->
	
	<!-- Select Project Category: VAS Projects manually -->
	
	<!-- Mail Configuration, non default sender email address -->

</JiraJelly>

We would find this very useful as well. Even the ability just to copy projects would cut down the amount of admin required to create new projects.

Just changing the description to ensure we attract the most votes and feedback on this issue.