Mandatory fields, why does it affect other Projects or Issue type?

huangbe May 21, 2014

Hi all,

Within JIRA I have created multiple projects, and within them multiple Issue Type.

Within each of the Issue type, new screens and screens schemas are created for each.

Just now I switched the "required" on for some of the fields, expecting them to to mandatory for screen that have them in its configuration.

But what's happening now is the mandatory fields I have switched on, they are affecting other Issue type. Meaning the particular fields is not even on the create issue screen, yet when we click on "Create" button, it shows a error message "XXX is not populated"

As mentioned in my second sentence, I have created seperate screens and screen schema, so I really am no expecting them to affect another other screen. Why is it still happening?

Note: I did create all of the custom fields in Default Field Configuration , Is this where I'm going wrong?
If I have to seperate the field configuration for each of the screen, and each of the screen schema, how do I do that?

2 answers

1 accepted

1 vote
Answer accepted
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.
May 21, 2014

Screens have nothing to do with mandatory fields, they are just a list of fields that will appear when you try to do things with an issue.

The field configuration, where you make a field mandatory, is the important thing. If you have a field configuration that is used for every issue type in every project, then making a field mandatory in that field configuration will make it mandatory in every project and issue type.

You need to have different field configurations by project and issue type.

Anita Sándor July 29, 2019

Hi Nic,

 

I know that this is an old post but this issue still exist in Jira. I am struggling with resolving the problem by setting up different field config schemes and field configs per project. The funny thing is that once I made a field mandatory for one field config, that field will be shown as mandatory on other projects with different field configs.

Also, I do not understand why a field config for project 'X' contains fields associated with screens that do not belong to project 'X' at all but other projects.

Thanks,

A.

Lan Zhi Xiong August 27, 2020

Hi Nic,

Currently, I'm using Jira Software version 7.11.1, and I'm also facing the same issue as Anita described.

Any clue or advise?

Thanks.

Xiong

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.
August 27, 2020

I probably missed her reply when there was a missing mail phase.

I think Anita was struggling with the complexity of field configurations, and I hope she managed to work it out.

Field configurations and Field configuration schemes are not project items, they are things projects refer to for instruction.

A project looks at a field configuration screen to tell it what field configuration to use for each issue type.

Where I think Anita was stuck was not creating and amending separate field configuration schemes.  When a field configuration is shared by two projects, a change for one affects both.  The field configuration scheme lets you have separate field configs.

Like Lan Zhi Xiong likes this
0 votes
huangbe May 22, 2014

Thanks Nic, you are correct. Purhaps I knew all along I have to create different field configurations for each project and issue type. I just didn't want to do it because it's so time consuming.

Why is JIRA so hard and time consuming to administer? Everything has to be done 3 or 4 times, I have to navigate to multiple pages just to do one thing?
(No need to answer, they are rhetorical questions, I'm just having a whinge)

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.
May 22, 2014

Well, I know it's a rhetorical question, but I do empathise with you. The basic answer is that if you want flexibility, you end up with complexity of setup. A lot of software is far more simple to configure, but because of it's inherent simplicity, can't be used for clever stuff. Some goes to the other end of the scale and is so complex, you can't even get to the flexibility because it's just too hard. Jira is somewhere in the middle. But there are things I'd like to improve, especially around field configurations.

One minor piece of advice though - don't create schemes for *every* project. Try to create a standard way of approaching a type of project, and then reuse as much as possible. For example, the last organisation before I went for a bit more flexibility in my career used Jira for incident tracking, monolithic development, several Agile variations, a risk register and a few other things I won't bore you with. The dev projects are the best example - we had 8 distinct schemes (actually 3, 3, 2 - split by business unit), and 500 projects using the 8 schemes.

Suggest an answer

Log in or Sign up to answer