Hi stevenspyrka,

I'm not aware of the behavior you're referring to and am unable to replicate it. I think it is a separate issue from this one. Could you create a support request or contact me directly?

Thanks,
Dave

Hi Dave

could you please clarify since it would not make sense to have such a behavior .We planned to migrate to 7 next week.

bests
Jan

Hi Dave,

I am sorry to inform you that you are wrong.
If I have a project with its own issue type schema with issue type A,B,C,D,E,F and only A and B occur in the Default Schema then I can only move issues to an issue type that exist in the Default Schema. Even if the Default Schema is nowhere assigned.

Regards
Steven

Hi everyone,

As of JIRA 7 (released on October 6, 2015), new projects are not created using the default issue type scheme. Depending on which project template you choose, a fresh set of schemes will be created for you. These new schemes do not use the default issue type scheme.

If you would like to create a project that uses the same schemes as an existing project, we have introduced a new "Created with shared configuration" feature when creating projects. Simply select an existing project, and JIRA will create a new project that shares all the same schemes as the existing project. Learn more here.

While we have kept the default issue type scheme for now, it is not used by default unless specifically selected and we expect to remove it in a future release.

Regards,
Dave Meyer
Product Manager, JIRA Platform

+ This issue is open since 9 years please fix it now.

Another one bites the dust here. Please change/fix this issue.

Bitten by this one today, would be nice to see it fixed

Considered this? https://marketplace.atlassian.com/plugins/net.youngaweb.jira.issue-type-ui-filter

+1 This should be very useful.

Please fix this ASAP. We have 50+ projects that actually do use the global default scheme, but when we need to add issue types only to certain projects, we are unable to remove these issue types from the global defaults. This causes an extreme headache every time we need to add an issue type to a specially configured project as the issue type gets added globally without the option to remove it.

This bug was reported over eight years ago. The fact that such a simple problem still has not been fixed reflects very poorly on Atlassian, in my opinion. I don't consider this level of quality acceptable.

Yeah, you can see why they are added to this scheme, but it makes it a bit of a nonsense that you then can't actually use it for any real purpose because of it. It just ends up being yet another thing that has to be changed whenever you create a new project.

+1
If the scheme cannot be edited so that it can actually be used by 'default', it shouldn't really be called (or treated as) the default scheme.

+1

+1

Yeah, this really needs to be fixed. We just merged together several JIRAs and now we are stuck with a mountain of issue types in the default scheme, and a lot of the projects from the other JIRAs we are merging with used the default scheme. To make matters worse, a lot of those issue types go with projects we don't even use anymore and no longer have any meaning, but we have no way of getting rid of them with out starting a whole new jira and inputting everything again manually (which will never happen).

+1

Amen! Kill the clutter.

Adding my vote to this. When you are not just using Jira as an issue tracker anymore but also as a project management tool then the Default Issue Type Scheme starts to get cluttered up with cruft that doesn't belong there at all.

Oh I have the same issue in 4.4.3, sheesh where is the answer here ? I see attachements what are they for ?

We migrated from another issue tracking system, and have decided to keep the original issue type names in order to make the migration easier on our users. But we only want these issue types to be availble for a single project. So we had to create an issue type scheme without these issue types, and for each new project we create we need to remember to apply this scheme. It was much easier (and more future-proof) if the default scheme would not have those issue types, and only include them in that single project's scheme.

We had to change default issue type scheme for 90+ projects and with help of some shell script and Selenium that was done in no time. We are using Jira 5.0.6.
To generate Selenium script replace [NAME OF NEW DEFAULT SCHEME] with name of your new default scheme in both files and [NUMBER OF PROJECTS] in shell script with number of projects that currently use default issue type scheme. Also replace [URL TO YOUR JIRA] in ChangeIssueTypeJRA-11222 with url to your JIRA Installation . Then run shell script, it will create Selenium script.

Use at your own risk, always test before using in production.

Oh man! I need to create a separate scheme for each type of project Just to add several custom issue types fields to one of the projects. this is suxs.

@chad maybe the Atlassian Product Managers and CEOs would be interested in constructive feedback from you on their various products? http://www.atlassian.com/company/contact/contact-ceos

Oh, if you need something rather lightweight, Wunderkit seems like it may even get the job done (rather than bothering with JIRA, I mean).

+vote! Please, Atlassian - have you even looked at this?

Stay away, markdw! Atlassian don't know what they're doing. Go with a product made by people who are good at software development, like http://apptrajectory.com or http://pivotaltracker.com.

Added another vote to what turns out to be a long list of outdated basic functionality I discover is missing during my evaluation.

Yes, this will be the great feature for the customized JIRA apps

I agree, the feature can be very usable

This would be a welcome improvement, currently it's preventing me endorsing a switch from bugzilla

I agree, this is a necessary feature. Please implement it.

You're right. I've turned down the mischievous fun to a more normal level.

I'm just another Atlassian customer, losing a little of my soul every day as I muck about in their under-thought series of kludges.

I'm sure you think it's all in mischievous fun, but putting [Atlassian] on your display name is certainly one way to make entirely the wrong sort of name for yourself.

On the other hand, if you actually work for Atlassian, I'd be expecting a tap on the shoulder in about 20 minutes.

I don't get why anyone wants this. If most of your projects aren't using all of the 70 issue types that have organically popped up over the past four years of your corporation's JIRA instance, then you're doing it wrong! Support queues, development queues, and ops queues should all use the same issue types. If you disagree, we'd rather you stop using JIRA altogether. This default is sensible, and we're sticking with it.

Agree, this is needed - especially when you add greenhopper and it adds 3 new issue types that duplicate existing issue types I don't even need. What a mess - help!

Hellloooo??? Just tripped over this. Please fix it.

It has my vote as well. In our setup, the consequence of this is that new projects get an invalid combination of an issue type scheme (the default one) and a field configuration scheme (the default doesn't include the field configuration we are using for the extra issue types). "Invalid" means in this case: we don't want this combination of issue type scheme and (absence of) field configuration scheme to occur.

Voting for this too. I don't get why there are customizable issue types if doing so litters the global issue type list too. It makes it a pretty useless feature unless the JIRA instance is only owned by one group.

This is a major issue that has been opened for two year. Why is there no work log?

This is causing a lot of problems for because I am using JIRA as an issue tracking system and a service desk. This means that when developers and testers raise a new issue in a project that uses the default JIRA issue type scheme, they see all sorts of waffle in the issue type options such as hardware request, network request, etc. I am going to have to create an additional issue type scheme to get around this (i.e. additional maintenance overhead) because the default issue type scheme seems to only be a bucket where ALL issue types are stored rather than only those that I wish to select. Please, Atlassian, consider changing this

We have extended Jira to be used as our Change Management process, of which we want to track all such tickets only using a specific project type. Due to this limitation, we are now forced to change the Issue Type Scheme on all newly created projects which constantly causes confusion as we have a number of project creators and leads.

Hi there,

We're also suffering from this problem. We have teams that work on software, hardware, design, etc, and don't want to have to create a separate scheme for each type of project, but because we have one project that needs custom issue types, we're forced create custom schemes for all of our "Standard" project type.