When you perform a json export of issues in OnPrem Jira server, then try to External System Import in cloud, the import process fails on every issue that has a status that is NOT in the DEFAULT Jira workflow.

So in order for this import function not to be crippled YOU NEED TO FIX THIS and make available the ability to change the default workflow so that we can add the necessary statuses to the default workflow so that the import doesn't fail on 10% or more of the issues being imported.

Hi sonny.dewit,
In case you are up for a cost-effective third party solution that's hosted by Atlassian to avoid the mentioned unnecessary steps in project creation.

Project Templates for Jira offers an efficient way to design custom project templates based on existing projects or Jira's built-in templates within a Jira lookalike user interface.

• Customize the templates configuration to meet your unique requirements

• Give non-admins template specific project creation power 

• Customize the UX & information displayed to non-admins 

• Clone project versions, components and project role actors

• Avoid the technical debt of unnecessary created Jira schemes/configurations

The app is built on Forge with no data egress, no sensible information stored and completely hosted in Atlassian's cloud infrastructure. 
Please let our support know if you have any questions.

+1

Any update on this feature?

Dear Atlassian, can you please give an update on this feature request? It's been 4 years since your last update...

This would be really useful to have ... we just finished a massive Jira clean-up project as none of our reporting was making sense given everyone had created their own workflows, issue names, types etc and all of that could have been avoided if we're able to change the default workflow rather than having users create their own (which will always be a human error point).

Hey sonny.dewit,

Thanks for sharing your experience. We definitely acknowledge that setting up the initial project with a new custom configuration is clumsy and we are working hard to address it. Unfortunately, solving this problem in a really sustainable way that scales down to small teams just getting started with JIRA all the way up to massive enterprises involves some pretty substantial changes. It will take us a while to get something out the door, but rest assured this is something we're working on.

Dave Meyer
Senior Product Manager, JIRA

In the category of feedback for any planned project setup improvements, this is what I've been working through today:

• Create the first of a set of new projects that will use a shared set of workflows, etc.
• Select one of the three default basic project types. This creates a simplified workflow (etc.) tied to this specific project.
• Try to edit the simplified workflow to what the project needed and so it can be used for other projects.
• This seemed like an incorrect way to go, so I throw away the project and its automatically created simplified workflows, schemes, etc. one-by-one and start from scratch.
• I reverse my process and instead first create the workflow (etc.) that I need for the set of projects I'm creating
• (2) I create the first of the set of new projects
• (2) Select one of the three default basic project types.
• Assign the correct workflow (etc.) to the project
• (2) Throw away (one-by-one) the remnant workflows, schemes, etc. that were created when I was forced to select one of the basic project types.
• Create the additional projects using a shared definition.

The "Create project with shared configuration" feature helped a great deal starting with step 10 of this process. But it's still a struggle to create a new project of this type.

That's a great idea I wasn't aware of, thanks. I've just created a template project and tweaked it a little to be generic so that I can use it as the base for future new projects.
For those who haven't found it yet there's an option at the bottom of the dialog when you create a new project to use a shared configuration.
https://confluence.atlassian.com/adminjira/jira-platform-releases/jira-7-0-0-platform-release#JIRA7.0.0platformrelease-Sharedconfigurationsforprojects

In JIRA 7 you can use "Create with shared configuration". You don`t need this function in the new version.

1. Create a template project with your user-defined workflow.
2. Create a new project with the "Create with shared configuration" option.

That`s all.

such a basic requirement being there for 9 years?

That's unbelievable! Please Atlassian say truth - are you using Jira at all?

I can imagine some pieces of code can be hardcoded, but not so basic? As long as you modified a workflow, isn't it obvious that you're going to use it?

Ahh what I'm talking about, my comment won't event be read and would be drowned in bureaucracy procedures of your management.

Agree with Teddy Ngo, this request is unfixed since year 2006.

Why is such a common request so difficult to implement?

Seriously? such a basic requirement being there for 9 years? Totally agree with @Stuart James.

Seems a bit ridiculous i can upload a custom workflow or import one from a market but i can not use the one that was developed and approved by our business requirements. I have no choice to select some other "project type" which then copies workflows and schemes for me to go around within the project re-assign them to the one i wanted to use and then delete all the extra ones that were created.

I just discovered a built-in script in the Script Runner called Create Project. It does all I need.

Indeed.
I voted for this request few months/years ago.
Just like the request to be able to use digits for project keys for Jira OnDemand.
Just like my remarks regarding very poor OnDemand speed when accessed from Belgium.

This week I think i've found THE alternative for our needs: Microsoft Visual Studio Online.
It contains project/tasks management using custom workflow/Scrum/Kanban.
Data can be browsed/edited directly from visual studio/eclipse.
Free for 5 users.

I recommend you all to test it.

Soon it will be a decade since this issue was created.
Damn it happens with every feature that I need. I'm starting looking to a solution, than discovering that this issue already reported and usually it's been done about 5-10 year ago. None of them were really accurately reviewed, just declined or deferred.
I'm starting doubt are these issues really reviewed by team leads or developers? For me it looks like it goes through standard support team and never reach the person who can really understand a meaning of it or make a decision.

Company Brands Can Then Set a Workflow for Themselves and make it a one-time Task for all their projects unless they wish to change it. Should be resolved.

Yes, please.

Vote up on this issue. We would also need a project template where we can assign our custom workflows, notification schemes, resolution types etc.

This is another no-brainer that Atlassian needs to implement. Our Workflows and Schemes, Issue Types and Schemes, etc., have all been customized to meet our needs. This is an Agile world, right? Well this isn't very Agile.

Piotr: I couldnt agree more. Workflow is just the tip of the iceberg. There are lists of project specific workflows, issue schemes, screens, fields, permissions etc etc.

*We want one and only of each scheme and the ability for a new project to create its own to be locked off. *

Somewhere there has been a serious design glitch and I really suspect that the product designers havent considered real usage. Why would any company want different management schemes for each project (of the same type) where the need for a standard approach let alone normal usage says keep them the same. The delay in getting this fixed when the manual process to switch schemes involves a few clicks and a confirm makes no sense. The priority given these issues needs to be sorted out.

This particular design consideration (default schemas) is also a problem in the service desk, where SLAs have to be manually setup for each new customer added. We want to setup 100 service desks .

Our company relies heavily on Jira and Confluence and we are all big fans of the whole product except for this. This oversight and subsequent lack of action is strange.

This is a wider topic: I would like to have an option to point a default workflow but all other project aspects: permissions, issue schemes, notifications, issue type scheme, etc. Having to set it up manullay is a painfull experience when working with lots of projects.

We also desperately need this functionality at our company. Not only do we have a number of new projects created on a weekly basis, but our project managers are finding the manual steps to change the workflow scheme for every new project to be tedious and unintuitive. I'm not sure why this feature cannot be implemented but it would surely save us all a lot of time.

Hey Gerdt,

I'm not using the cloud version myself - its actually easier from what I can tell as you can simply upload the plugin file (saves you from submitting the app to the store).

-p

Let's suppose not everyone is using the cloud version...

Hey folks,

had a quick look and it seems like you can install plugins on the Atlassian Cloud platform (no longer named "Atlassian onDemand" as Id mentioned before, sorry)

Basically you just need to do one extra step, in that you would publish your app to the Atlassian Marketplace - a super quick and simple process, with great support from Atlassian (I published an app on the marketplace just a few weeks ago - https://marketplace.atlassian.com/plugins/com.petermcconnell.plugins.jql.jira.members-in-role-function). All the information you need about the process can be found here:

https://developer.atlassian.com/static/connect/docs/developing/cloud-installation.html

Looking forward to seeing your work in the Atlassian Store in future

P

For OnDemand it might be possible to use Atlassian Connect: https://developer.atlassian.com/static/connect/docs/index.html

No worries - I'm not entirely sure to be honest as I haven't personally tried JIRA ondemand, however as long as you can still see the "Upload add-on" feature I can't imagine any reason why not. Nothing on the tutorial page stipulates hosted/ondemand so I'd imagine it would be fine.

Hope that helps?

P

Sorry @peter I meant OnDemand – edited comment to correct.

Yes absolutely - our own solution is self-hosted (not ondemand). The output of the tutorial is that you create a .jar file which you can upload on your "Manage add-ons" page ("Upload add-on" link to the right)

Good luck & I'd be happy to try and help out if you have any questions.

P

@peter.mcconnel, is this an option for those of us that are using OnDemand?

I honestly believe creating your own plugin is the best solution - worked for us. With no prior Java experience I was able to get a prototype working in about two hours? Definately worth looking into & opens you up to a bunch of different options.

The tutorial you will likely wish to follow can be found here: https://developer.atlassian.com/display/JIRADEV/Creating+a+Project+Template

You can export your current JIRA workflow as a .jwb and use it as you are going through that walkthrough.

Hope that helps & happy coding!

P

Good afternoon,
I would like atlasian people to tell me what the situation is the current issue?
or alternatively that atlassian people guide me to solve this problem.

I await a response.

Thanks and regards

Adonis Pate

+1 and also a long time to have such an issue open...

+1 - very important to save time and money on each project creation... !

+1

It's difficult to understand why it is still not possible to change the default workflow scheme for a project!!

+1

Hi Peter,
we will take a look soon, I have some more Java experience but currently less time.
Will respond asap

Just to throw my 2 cents back in the mix (I'd commented back in 22/Oct/13 12:07 PM on this thread), in the end we just created our own plugin to do this for us. It had the added benefit of allowing us to automate further tasks, such as automatically creating our scrumboard for us.

I'd never done java dev before so can't say that this will be the best example of how to execute this, but by following the docs and tutorials on the site I made https://github.com/rehabstudio/jira-rehabstudioproject

I hope some of you are able to use it as a guide for crafting your own plugins / give you some ideas for how to solve this issue. For what it's worth the plugin works perfectly (when you click on "new project" it appears as an option in the popup that displays)

+1

Adding in a voice of agreement on this one. It's a painful lack for me that every project we create needs to subsequently go in and be changed after creation when we went through the difficulty to set up a custom workflow for our organization.

Perhaps the problem is that this feature request's associated workflow doesn't have a "review" or "evaluate" stage.

+1

+1

Jira's workflows are powerful tools but pretty useless if you have to specify for each new project you actually want to use them...
+1

+1 please!

+1

Voted and commented +1 – Apologies to all watching this issue.

I had long assumed this was possible given how flexible JIRA usually is, and was shocked to find this feature was missing. This is a hurdle for adoption of JIRA within our organization – it's a harder sell if project defaults need to be tweaked each time a project kicks off, which is often, and users haven't learned to administer JIRA. As the JIRA advocate within the company, I'm trying to make it very simple and fast for other PMs to create a project and get set up without much configuration.

Why has this still not been resolved? It feels like a massive hole in an otherwise decent system. It means I have to give everyone admin rights because when they create projects they have to mess around changing the scheme. We may even have to move away from Jira because of this.

+1

Voted

I apologize to everyone for another spam email... but this has become silly.
For all future "+1ers" there is a vote function on this page that is specifically for indicating a +1, please use it. Comments are for when you have something substantive to add to the discussion, as such when you post a comment it emails everyone that is watching the issue, which is mildly annoying when the entire content of the comment could have been communicated by voting for the issue. What's more, a +1 comment does not count towards an overall vote tally, so if Atlassian is looking at the vote count, the comments won't help (presuming you did not also vote, perhaps you did).

TL:DR
Don't comment with +1, vote instead.

+ 1

+1

+1