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

Marcus O'Brien July 8, 2021

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.

2 answers

1 accepted

3 votes
Answer accepted
Markus
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
July 8, 2021

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 July 8, 2021

Thanks for the answer.

0 votes
Nic Brough -Adaptavist-
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
July 8, 2021

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)

Suggest an answer

Log in or Sign up to answer