Field Configuration vs Screen Configuration (Difference)

[Yagmur Gümüs]

Hello,

i have Question and my English is not really good, so i hope i can explain my issue:

It is possible via FIeld Configurations any Fields to Hide or to Show.  So this means i can control witch field should be displayed on a „Create Issue“ Screen. For Example, i can add a new field config for my „issue type“ and hide all the fields i do not want to show.

But this is also possible via Scrrens, and my problem is to understand the diffenrece between these two ways.

Thanks

[Nic Brough -Adaptavist-]

Ah, no, they are very different things.

A field configuration hides fields completely.  If you ever want a field to appear on an issue, it can NOT be hidden by field configurations.

A screen is a collection of fields that you want to present to the user at particular time (Create new issue, Edit an issue, View an issue, or while moving the issue through the workflow)

i think the bit to understand is that a field configuration always will hide a field even if it appears on a screen.

[Yagmur Gümüs]

OK, this means:

If i do not want a Field in any way in my project (for example because it es created for an other project) i will do this by hiding --> Field Configurations.

But if i want not to show a field (because its for the project but not for example for the create screen) i will do this by deleting it form the screen (respectively not adding to the screen) --> Screen Configuration

So field configuration separates the fields for the different projects and screen configuration allows me to separate within the project? Is the idea right?

Thank you very much

[Nic Brough -Adaptavist-]

Well, you're going in the right direction... Field configurations are handled one layer down from projects - they're done on Issue types. Of course, if you keep it really simple and ignore the issue types, then yes, you are spot on, you can use them to say "Show field A, only in projects ABC, DEF and GHI". But, you can use them to say more complex setups like "show field A in projects ABC for bugs only, and show field B in DEF for new features and stories, and both fields for the issue type 'arthropod' and 'bugs' in GHI" Yes, if you want to keep a field for a project, then you use screens to control where it appears in detail. I tend to put all fields on the "view issue" screen, then copy it for the "create" and "edit" screens, thinking carefully about what I actually need the users to do with fields, and think about how to handle them in the workflow. A typical example for me is for "Incident" type issues. When something goes bang, the users want it fixed immediately, so they raise an issue. The create screen has Summary, Description and a couple of other fields about gathering information from the user, but not fields like "root cause", because most, if not all of the time, they won't know. The RCA field is on "view" so you can see it later, and it's on "edit" for when you do know what it is, and it's on transition screens in the "analyse and prevent" phase of the workflow. Note you can re-use all of the schemes for many projects, and it's a good idea to do this. As a random example of one of my clients, they had development, operations, and project-management style projects (around 700 in all). We had one set of schemes for Operations, and other set for project-management, and six or seven schemes for the different development styles of working.

[Michael Tokar]

To add to Nic's answer, when a field is hidden in the Field Configuration for a project/issue type, that field effectively does not exist in the eyes of JIRA. This means that it will not be searchable in Issue Navigator/JQL, as it will not form part of the issue's index. This will also prevent other add-ons from manipulating/retrieving values for that field.

[Philip Armour]

Hi,

this topic interests me. To ask a slight variant on the question - are there any use cases where hiding a field through the Field Configuration (of an issue type) is a much better option than simply not including the field in any screens for the issue type? 

In other words, if Atlassian removed the option to hide fields via Field Configuration, what would be lost?

Many thanks in advance!

[Nic Brough -Adaptavist-]

Not a lot, for the end user.  Admins would have some "fun" unpicking where they've used hidden fields and making more screens for them

[Philip Armour]

I suspected that, thanks for confirming!

[Leigh Grealis]

I think there's another aspect here which is worth consideration. What are the performance implications for using different methods to handle displayed fields? For example, if you have a large JIRA with around 1,000 custom fields. A particular project may only have 20 custom fields with it's issue types having various configurations of these . I had always "assumed" (which usually comes back to bite me I suppose!) that explicitly hiding the custom fields in the field configurations  would give some efficiency improvements and likely performance improvements, especially when using filters on that project and it's issue types. However, I've never delved into the parts of the source code which would back up that assumption. Anyone any thoughts on the difference from this perspective?

Given I have a 1,000 custom-field instance I am working with I will try to see if I can do some simple tests (at either extreme) to see if my assumption is reasonable or if I have been wasting my time all these years...

[shruthi sj]

Hey all,

As i was going through this discussion, i have a real scenario here, lets say i have to build common process across all the JIRA project in my org, where there can be some exceptions,

in this scenario, if we are using same field configuration across all the projects inside JIRA and we dont some fields to be appear on on one project then we need o have separate field configuration scheme where screen scheme can remain as is.

Please correct me if i am missing something.

Thanks,

Shruthi

[Nic Brough -Adaptavist-]

You're right, if you want to do something different to the globally shared schemes, you'll want to spin off another copy of them to make the differences in.