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

Greg Williams June 12, 2020

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

GIIssueLayout.jpg

 

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

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.

1 answer

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
June 13, 2020

>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

Deleted user December 7, 2020

Do you know where can I enable this feature you mentioned: "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."? I can't share issue types across projects and don't know how to enable it (No projects available to be associated with scheme <scheme_name>).

Deleted user December 7, 2020

OK, I figured it out – issue type schemes can be assocaited with classic projects. Next-gen projects don't support it.

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
AUG Leaders

Atlassian Community Events