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; } } }

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

Accepted answers

All comments

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.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration