Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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

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. 

0 votes

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
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you