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

Why have a field config when we have a screen scheme ?

Marcus O_Brien_h96mm7

I saw this post 4 years ago that kind of answers my question, but I feel its not quite explaining it enough

https://community.atlassian.com/t5/Jira-questions/Fields-configuration-vs-Screen-scheme/qaq-p/579123#U1745326

Why do we need 2 separate things for fields - field config and screen scheme ?

Why cant these things just appear as config params in the screen scheme ?

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 scheme wouldnt be enough to describe what you want ? For each screen scheme attached to a type you can only have one field config, so when would there be a reason to create multiples. If you could have multiple configs it would make sense. I am missing something obviously, can someone explain how this makes sense.

Accepted answers

Markus_rixsng

Hi Marcus,

As a system administrator my answer to the reasoning would be to enable a modular approach.

Each project created has unique requirements, some may involve different fields on a screen, some may involve required fields on a field configuration.

The benefit of having those two actions in separate configurations is that it potentially halves the number of screen schemes and field configurations I need to make.

All comments

Nic Brough -Adaptavist-

I don't think my answer in the old question says anything about "why", it's more about getting someone past a block or confusion.

They "why" is better answered by "history and iffy design". Field configurations and screens were the approach chosen (if memory serves, for Jira 2) but you'd need to ask Scott or Mike exactly why at the time. The "why" now is simply that it's the way it's been done since then, it works ok(ish) and no-one has built up the oomph to do a complete redesign of field handling. It's not as simple as dumping the functions from one place into another though - field configurations hold settings that couldn't be done elsewhere, and there are some pretty heavy structural changes needed to move their functions to other places.

I think most people would agree "well, I wouldn't do it that way now".

I certainly don't like the three-tier system and would prefer only two layers - a global list of fields as we currently have is fine, and I'd throw away the field configs, moving the "renderer" into the list of fields, and hidden/mandatory flags etc into the screen definitions (this would make Jira more flexible and easier to admin)

Markus_rixsng

Hi Marcus,

As a system administrator my answer to the reasoning would be to enable a modular approach.

Each project created has unique requirements, some may involve different fields on a screen, some may involve required fields on a field configuration.

The benefit of having those two actions in separate configurations is that it potentially halves the number of screen schemes and field configurations I need to make.

Marcus O_Brien_h96mm7

Thanks for the answer.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

jira-software

jira-software-cloud