nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Fields configuration vs Screen scheme

Shani Mamka

Hey everyone,

I'm a bit confused between field configuration to screen schemes.

basically, if I want to define a custom field to specific issue type and specific project, I can associate this field with the issue type, and specific screen (from my screen's project).

So, why to use field configuration?

Thank you,

Shani

Accepted answers

All comments

Nic Brough -Adaptavist-

A screen scheme tells JIRA what screens a field will appear on for a particular issue type.

A field configuration tells JIRA some configuration details about the field when it is applied to an issue type - mandatory, type of input, and also if it is hidden.

Shani Mamka

Hey Nic,

Thank you for the quick response.

Marcus O_Brien_h96mm7

I know this is 4 years ago, but it doesnt quite answer the question of why we need 2 separate things for fields.

Why cant these things just appear as config params in the screen ? Otherwise you can list a field in a screen and then its not visible because the the screen scheme hides it - why put it in the screen then ? Would there ever be a case where the screen is not enough to describe what you want ? For each screen scheme attached to a type you can only have one field config, if you could have multiple configs it would make sense. I am missing something obviously, can someone explain how this makes sense.

Nathanael Motz

Not displaying a field is the typical case where I often question what the best practice should be. That is, do I hide the field in the field config or remove it from the screen? I usually remove it from the screen as that makes more sense to me. I also feel like it might be less confusing to others looking at the configs.

Since a field config and a screen scheme might apply to different sets of issue types I guess I can imagine a situation where it might make more sense to use the field config method as it can be quicker to implement. Any other reasons to choose one method over the other?