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

[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]

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?

[Rob Tull]

I have opted for field configs over screens in a number of cases because it reduces the fields shown in the bulk change interface. Our field list was getting quite long but we found that if no issue in a bulk change set has a field, then that field is not shown in the bulk change edit list - which improves the user's experience.

[Mason Mackey]

I am typically removing the fields from the screens if i don't want them on each specific issue type. a Bug issue has different fields when it's being created than when it's being resolved. 

how might i use the field config in place of screens? 

[Rob Tull]

If you want to display different fields at different times, that's what Screens are for. The field config is more for a situation where you want to control what issues apply to a certain issue type ever. For example, if a field should never be populated for a certain type of issue, then you would use a field configuration. If it should be populated but only at certain times, then you'd use a Screen.

[Deleted user]

It is been 2 years, is anyone still here?

I tried ,but still confused,like this:

This filed is only configured in Epic Screen,but when I save the Store it stll says "Affects  Version/s is required." 

In fact ,this filed does not actually exist.