@barry.pollard The "Create with Shared Configuration" is very misleading. It does NOT do what i explained. After the project is created, there is no direct link between the configuration of each project. So, if you change the Issue Type Scheme to a different scheme on the original project, that same change does not occur on the new project. Therefore the configuration of the project is NOT shared. It is only sharing the separate schemes selected for each individual configuration within the project.

Please look at the documentation at https://confluence.atlassian.com/adminjiraserver070/defining-a-project-749382822.html as well as a suggestion to change the name of "Create with Shared Configuration" here: https://jira.atlassian.com/browse/JRA-45840

Some of the pain in changing schemes in projects have been alleviated in the past when they changed what modifications can be done to a workflow scheme, but the need is still there to keep many projects in sync with all the same schemes.

"Create with Shared configuration" unfortunately is at least for me for the majority of projects I have to create NO real alternative to the original and suitable clone functionality. I wonder why this functionality has not been updated by Atlassian for the usage in Jira 7.x.

@abarylak "Create with Shared configuration" sounds exactly like what you want. Are you sure you understand how this works? The config is shared even after the project is created - there is no copy per project.

This actually works very well for me and largely negates the need for this request for me. Personally I hate the way that JIRA creates project specific config each time you create a new project. Gets very messy and duplicates a lot of identical or near identical workflows, screens, fields...etc. and loses any work you've put into workflows. So shared config for me all the way and I think this should be encouraged more in JIRA as the default to use, rather than hidden at the bottom of the screen.

However I can sort of see the need for @scott.soltero wish to be able to clone in some cases, so that if someone is intending to change the workflow (for example) just for that project then it doesn't affect other projects. But to do that I personally prefer to create with shared config initially, and then change Workflows/Screens/Fields to a project specific one if needed. And copying a workflow for example, and then updating the project to use that copy, makes this relatively easy (though admittedly a two step process).

@Pete W, the "Create with Shared configuration" is what I want to avoid. What I need is the ability to create templates that deploy unique instances of each scheme. That way I could create the 3-4 base line templates I need and deploy projects with only minor tweaks.

No, that is not what we want. That only creates the project from a template, but is then completely separately managed. It is the same as using the ScriptRunner built-in script to copy a project to a new project.

What we are looking for is a way to give a bunch of projects a specific scheme, so that we can apply workflow/notification/permission/issue type/etc schemes to the project scheme, and then any project which uses that scheme also inherits the same changes. Basically so we can ensure a specific group of projects always has the same configuration and behaves in the same way. It causes a lot of user confusion when a certain issue type behaves in different ways between projects, or if a user gets a notification for something in one project but not in another. They get really confused and cause additional administrative overhead to deal with questions around these inconsistencies.

Hopefully this issue will gain some traction sometime before i retire... i'm only 33

In my create new project there's a link at the bottom that says "Create with shared configuration"

Is this what some of you want? did the trick for me.

We just upgraded from JIRA 6.3.15 to JIRA 7.1.4, and I strongly concur with the previous sentiments on creating new templated projects to avoid having to delete lots of unneeded and tailored stuff (workflow scheme, workflows, issue type screen scheme, screen scheme, screens, etc.). Allowing an admin to copy a project would be a much more efficient strategy.

@David Skreiner vote +1
copying the schemes is a truly horrible!

Could you try not always selling add-ons as "solutions" or workarounds to JIRA issues?
While you're at it, please also make it so JIRA no longer creates a dozen copies of default schemes whenever one creates a project.

Adding my vote to clone a project, this is a huge time saving feature that will aid my team and I.

How is this not a priority?

Because Atlassian doesn't care. There are dozens of tickets just like this one with huge numbers of votes, comments, and customer support which have been ignored by Atlassian for about a decade. They just don't care.

–
Join the Atlassian Doesn't Care Team. Change your profile name to Atlassian Doesn't Care today!

JIRA, please look over the 100+ comments and the 500+ votes on this ticket and realize that you need to deliver a solution to your paying customers. This feature was requested 9 years ago. This is one of the most voted on suggestions. (14th most voted on at the time I wrote this) How is this not a priority?

I completely understand TJ. We are actually have our own implementation of what you describe above, creating JIRA Projects out of templates, elements, Confluence integration, Source Code (SVN or Bitbucket), Maven and more integration. Just consider it a one stop portal for ALM tools with integration built-in based on what your project need). I did not realize there's some tool out there that is pricing this much for the same functionality.

@Gabrielle, the automation script the company provides does more than simply copy projects (it has some very nice features to allow selecting pre-defined elements and creating projects + confluence space with page tree and content, etc). It's a great solution, but not for money they want to charge.

The point of the matter is that it's stings to be told you must pay more to get greater functionality after already paying so much.

Russ said it perfectly:

...whilst it is obviously desirable to have a community of developers adding functional richness to a start-up product, eventually the people who pay enterprise software prices will start to expect continuous functional improvement in their SaaS product.

TJ, that does not seem right. Copying an existing JIRA Project costs 10k now? I should be living in NY then!

+1 to the sentiments shared today.

I voted for this issue shortly after we adopted Atlassian, having left a system that does provide project templates.. that was almost three years ago.

Now we have a 10 page 'guide to creating projects' for our sales and project management teams, simply to describe how to copy pages in confluence to set up information structure, manually create issues from each page, create the project board with our designated columns, etc etc.

I found a company who seemed to have found a way to automate this, and they wanted a measly $18k to implement it for us, or they were willing to let us use their code for a discounted $10k.... neither option being anywhere near affordable for us, especially in light of the thousands we pay per month to use Atlassian's solutions.

This is the culture that Atlassian has created, and seemingly continues to promote, and it's pretty sad to see.

I agree with Russ.
And sadly, it doesn't stop them of wasting effort in changing the licensing scheme every 2 years or so, increase by thousands the renewal fee while pushing missing feature toward the Marketplace.

Atlassian will indeed have to make a choice: Lower the core price and have customer rely on expensive plugin in the Marketplace, or start to actually listen to customer and start fixing / adding missing core features.

After nearly 8 years with Atlassian, I've got the feeling they're more inclined in creating bait features, adding features to attract new customers, but doing nothing to the customers who are integrated into Atlassian products who can't really look for an alternative without breaking their whole system or losing historical data.

Completely agree with Kevin's comments above.

JIRA have given themselves a bit of a problem with the marketplace; whilst it is obviously desirable to have a community of developers adding functional richness to a start-up product, eventually the people who pay enterprise software prices will start to expect continuous functional improvement in their SaaS product.

I cannot recall a single idea that I have supported being incorporated into the product in the two years we have been using this system; I can recall many ideas that have been dismissed by the product team with a note to say that there is someone willing to take ever more money from us to supply what is obviously a very popular enhancement.

Atlassian will need to make a choice on this at some point, and decide if it is the marketplace partners or the paying consumers who are the priority for them.

(Speaking as a fan and evangalist for Confluence+Jira)

Project curation should NOT be an add on! It should be a core offering, if Atlassian fancy themselves as something for the enterprise instead of for teeny teams.
Judging by their IPO success, I hope they do acknowledge this and start maturing their product PDQ.

+1 to Scott's comment

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.

"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.

Thanks for the info @Bartek, appreciate it. Will be nice to see more helpful plugins become available for OnDemand customers.

We'll still probably move to hosting our own very soon, as the limitations are costing us quite a bit of time and headaches, but good to know for the future and others who come along!

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.