Do folks bother creating Jira field configuration schemes?

John Price_dcio76

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_

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!