Issue type field still showing after being removed from screen

[Zoltán Lehóczky]

I've removed a lot of fields, including Issue Type from the screen used by a project's screen scheme (because all issues are really of the same type). Indeed only the fields remaining in the screen configuration are shown when creating an issue, but Issue Type remains shown.

How can I remove the Issue Type Field from the screen?

Thank you.

[Nic Brough -Adaptavist- · Accepted solution]

You don't.  Issue type is less of a "field" and more of a "critical key structural concept for a JIRA issue" and hence it is completely mandatory, even if you have only one type in the project (or indeed whole of JIRA).  Although you can get rid of it on edit, create and transition screens, it's always going to appear on issue view, because it's required for the system to work.

[Zoltán Lehóczky]

The View screen is less of an issue but I see it on Edit/Create still. The project uses a single screen everywhere (for create and edit, and there are no workflow transition screens) and under "Field Tab" it doesn't have Issue Type listed, but still, it appears in the editor. I get it that this data is crucial for JIRA but it's useless for my users so I'd like to hide it (when I said "remove" I meant "hide from my sight", of course it's fine if it's technically still there just not appearing).

[Nic Brough -Adaptavist-]

Sorry, yes, I forgot, you need it on the create screen because you have to set it. You can't work without it, you *have* to have it. The answer remains the same though - you have to have it there because it is an absolute requirement. Doesn't matter if you have only one type (that's vastly under-using JIRA's power), the fact is that it is built for many issue types and requires you to enter it.

[Zoltán Lehóczky]

I see. Well, this is not something nice. Thanks for your help.

[Nic Brough -Adaptavist-]

It's an edge case - you might well be the only Jira user with only one issue type.

[Zoltán Lehóczky]

I don't think so: we are heavy users of JIRA and also use it to track a variety of "issue-like" data. This is about a particular project not needing issue types since the data tracked is simple in this matter. For most of the projects this is not the case but it's hard to imagine for me that you wouldn't want to utilize JIRA for use-cases where all issues represent the same kind of "stuff".

[Nic Brough -Adaptavist-]

So you are using different issues types, so you do actually need it to support the capability to move issues to other projects.

[Zoltán Lehóczky]

Yes, but I fail to see why this matters. It's an internal stuff of JIRA, I get it, what I don't get it why any internal technical detail should affect the visibility of UI elements. That's it, really.

[Nic Brough -Adaptavist-]

Because it's not an internal technical detail - it's a critical piece of the configuration. That's it really, it's too important to hide.

[RPandyaram]

@Zoltan Lehoczky , You have to define issue type scheme to allow one issue type that you want to be.

Associate this scheme to your project.

Update your screen scheme for this issue type.

This will keep single issue type by default .

[Zoltán Lehóczky]

Thanks, but this is what I've done.

[RPandyaram]

But the Issue type will be shown inspite of single issue type availability . I missed to mention this point.

[Zoltán Lehóczky]

I see, this is what Nic explained too.

[Vladimir Nikitin]

Thank you Nic. Your second suggestion helped. I went thru the documentation and found 

"A custom field can only have one context per JIRA project. So you cannot have multiple contexts for different issue types in the same project."

Multiple context is required in my project. So I think I will go with two different screen approach.

Any chance this restriction/limitation will be removed in future 

[Vladimir Nikitin]

I have a similar question.

I want to have different drop down list based on the Issue Type. Should I have define two different screens, with only one filed different? Or there is any other shorter way?

[Nic Brough -Adaptavist-]

You could use two different screens. Or you could define a single drop-down and give it different "contexts" for the different type. Go to custom fields, and find your field, and click configure. You should find you can add a context with a different list of options, and then say "use this for bug" and "use the other context for everything else"