Do folks bother creating Jira field configuration schemes?

[John Price]

I'm a long-time Cloud and Data Center admin. I'm aware that using the Default Field Configuration without custom field contexts means that Jira stores a value for every single issue and every custom field. The symptoms I've seen are:

• In a Data Center instance with 10 million work items, there are 10 million (often useless) values in the customfieldvalue table.
• When using the issue REST API, issues return every custom field in a giant list unless you specify fields in the query string.

However, creating a new Field Configuration and then going through and clicking Hide on hundreds of fields is a huge pain, so much that I've sometimes created a base configuration template with all custom fields hidden, then copied that so that I click Show 10 times instead of Hide 990 times.

How do other people handle this? I believe that just setting the context for each field accomplishes similar goals, but that has its own problems. With 1000 projects and many issue types, it's clunky to use the multi-select fields and all too easy to accidentally deselect projects.

Thanks!

[Matt Doar _Adaptavist_ · Accepted solution]

Yes, all familiar concerns to me. I thought that the issue REST APIs would only return fields that are in the screen scheme for an issue, not all fields?

Beyond that, field configs used to be how we set default values for system fields, but that now has it's own page so shouldn't be necessary. There are better ways to Show/Hide fields such as ScriptRunner Behaviours (disclaimer: I work for Adaptavist who make ScriptRunner).

For makiing admin changes to many field configs (or other schemes) I found myself writing ScriptRunner scripts to update all the schemes without the manual pain of those 990 clicks. I do agree that keeping the number of schemes, of all kinds, to a minimum is a good practice to reduce maintenance cost, but sometimes the users just have a really good reason why they need one special change for their project!

[Matt Doar _Adaptavist_]

And yes, the use of multi-select fields for the list of projects and issue types in field contexts was astonishly annoying! Looks like that has been improved in more recent versions of Jira DC though.

[John Funk · Accepted solution]

Hi John, 

I guess my question is why are you hiding all of those fields? If you are trying to get by with a single screen scheme for your entire org, that wouldn't make sense. Not having a Context associated with your Custom Fields will result in performance problems. The vast majority of your custom fields (95%+ in my opinion) should be attached to at least one project and or/issue type. 

[John Price]

I'm trying to avoid using the Default Configuration Scheme, which has every custom field in Jira set to Show by default. When I create new projects, I want to use a non-default scheme that has field visibility and rules common to a smaller group of projects. I know how it works in DC, but for Cloud I'm not sure how the new field layout layer impacts things. Specifically in DC:

1) Using Default Field Config alone = every issue in Project X gets a stored value even if fields are not on the screens.

2) Default Config + Custom Field Context to limit projects = Project X won't store a value if context is for Project Y only (99% sure).

3) (Cloud Only) There are now Field Layouts. I don't know the impact of hiding things there on data storage.

[John Funk]

Agreed 100% - in my opinion the Default of any scheme should not be attached to any project. Create a copy, make any changes needed and make that your base. Then make a copy of that when you need to deviate. 

Yep, simply using Custom Field Context with at least one project associated solves all 3 above. Global fields are different animal, but you really shouldn't have too many of them. Every time a custom field is added, 99% of the time it is for a specific project or set of projects in my experience.