Custom Fields, Contexts and Schemes best practices

[ChristopherChilds]

We are planning to perform a long overdue spring cleaning on our Jira Server, specifically I have questions relating to Custom fields.

Custom Field Contexts.

According to the documentation, most of which use drop lists as an example.
If you see the same field required by different projects but the values need to be different you should use contexts. This will help with performance.

But, in all the examples I have seen the Custom Field, by default is set at the global level. Why would you do this? isnt it better to set the custom field straight at the project context level? does it make a difference?

Now we use the Contexts, what is the point of a field configuration scheme? we, it seems, create all fields in the Default collection. I can not see any advantage in the Field Schemes as it is Fields that are most requested and, as I can see, we have been doing this to save time. So, I am asking what is the best practice these days with regards to using Field Confiruation Schemes?

[Nic Brough -Adaptavist-]

It is all quite involved, with three things you need to look at for custom fields.  

To try to keep this simple, I'm going to answer your questions in totally the wrong order!

To get a custom field put in front of a user, it must

• Be on the screen they are using
  • This is the simplest bit - a screen is just a list of fields to offer when someone does something
  • Best practice: only put fields on screens when they are useful for the what the user is doing with that screen
• Be not hidden in the field configuration
  • Field configurations are a set of options for handling fields, one of which is the option to hide fields.  (There's an essay on why it's there when we've got field context and screen content that can show/hide fields as well, and my opinion is that the hidden flag should have been dumped years ago, with everyone doing it with screens instead, as they make more sense. 
  • My recommendation is that the best practice here is to never use field-config: hide, if you don't want a field on a screen, don't put it on the screen)
• Be valid in the field context for the project and issue type
  • Custom fields are created as global entities by default, mostly to encourage people to work together - common shared ways of doing things and reporting on them.
  • Best practice though is up to you and your needs for the field.  As below!

The main point here is that screens and field configurations are about whether a field is displayed, but a field context is whether it even exists.

I find it easier to talk about this with an example.

Imagine a custom field that you create with a global context, and you populate it in issues ABC-123 and DEF-456.

If you remove it from all the screens in ABC-123 or hide it in project ABC, the data in the database is still there.  You can still put it back on screen or unhide it, and if you've only removed it from screens, you can still search and report on it!

But if you change the context from "global" to "only project DEF-456", then you will lose the data on ABC-123.  The field does not exist for ABC anymore, there's nowhere to store the data for it in the database.

The most important effect of context though is a technical one.  This explanation is technically totally wrong, but it is a simple human way to explain how it appears to work:

Fields are indexed, and the indexing holds data for all fields, irrespective of their content or lack of it.  So if you've got a global field and 100,000 issues, the index holds 100,000 records.  That's an overhead when you're searching and reporting.  Jira 8 massively upgraded the indexing engine and reduced the impact of all these "hey, I'm empty" records, but there's still some overhead in it.

If you have a project DEF with only 1,000 issues in it, and you take the field context from "global" to "Project DEF only", you now only have 1,000 records for the field in the index, making it smaller and faster.

And that's why we use field contexts.