Creating an issue type with custom fields and adding to an existing project

Greg Williams_nvfbk4

Jira Cloud question:

I'm relatively new to administration and I have a user requesting for a customized Issue Type (we'll call it "Ops Request") and add some customized Fields to this Issue Type.

What he wants is for this one specific Issue Type to have a nearly completely different set of Fields for users to enter information (apart from the standard required Fields, like Title and Description) and add it to his existing Project in Jira.

I have had a difficult time trying to accomplish this request for the customer. I've created the Issue Type, then when I tie it into a Project, all of the other Issue Types reflect that new Issue Type's fields, or if I add it to a Project, all the customized fields disappear and it mimics the fields from all other Issue Types within that project.

The closest I have come to accomplishing it was from this post here where I went through the steps and created what I thought was the correct process, but I'm certain I have gone onto a different tangent as what I've done is created all new Issue Types for the existing project (basically the project name followed by Task, Epic, Spike, etc.) because I gathered that's the only way I could create a custom Issue Type and then allow it to be separate from the other Issue Types and their fields.

The more I think about this, as I'm typing, the more I'm thinking what I need to do is add the new Issue type as a separate Field Scheme?

See image below for what I *think* I should be doing...

 

And what I ended up doing looks more like this (using a test project I set up):

What he wants is for basically all of his current Issue Types to be left alone and to just add the Ops Request, with it's own customized Fields.

Any help is appreciated. Guidance towards reference materials is also welcome.

Nic Brough -Adaptavist-

>is add the new Issue type as a separate Field Scheme?

No, but you've used one of the two terms that tells me you're in the right area.

There are two main layers to this.

1.  The issue type itself. 

Issue types are a global list, so you just add "ops request" as the first step.  However, that does nothing other than make it available.

To get a project to use it, you have to tell the project to do so.  This is done with the "issue type scheme" for the project.  You may find a scheme is shared, so you may want to create a new scheme for this.  As a potentially conusing option, you can also add issue types while you're doing admin on the project or scheme directly.

I think you've already got that done

2.  The issue type configuration

The issue type in a project is what all the configuration hangs off.  When someone selects project and issue type, that combination determines what fields, screens, and workflow are used for the life of the issue

Concentrating on the field side, there are a couple of things to look at

By default, fields are added globally.  They become available to all projects and issue types.  (Again, potential confusion, if you're adding them from project admin, they may be project specific). 

There are several ways to tie fields to projects and/or issue types

If you go to the list of custom fields and find one of the new ones, you can use "configure" to give it a limited context.  In this case, you could set a context of "ops request only".  The field would then only exist for that type.

If you use "field configurations", you can have a different one for each issue type in a project.  These have a "hide" flag, so you could say "hide new field on all issues, but have a second field configuration, associated with ops request in this project, which shows the field"

Then there's screen schemes - similar to field configurations, you can have different ones by issue type that say "use these screens for this issue type", having one set of screens that include the field, associated with ops requests, and a second that does not show it, for all the other issue types in the project

I'm fond of the diagram on https://confluence.atlassian.com/adminjiraserver/project-screens-schemes-and-fields-938847220.html for all of this.  But note that it only applies to Classic projects

Next-gen projects are very much simplified and https://confluence.atlassian.com/adminjiracloud/configuring-issues-776636329.html is more appropriate