Field configurations; auto hide new field

Problem

We have almost 1K custom fields, and making bulk changes gets really slow when JIRA is trying to load so many fields.

Current Work-around

We've made an "All Hidden" field configuration that we can copy and then show the fields we need for any given issue in a project, BUT the problem is that when new fields are created, not only do we have to fix the "All Hidden" field configuration, but ALL the other existing field configurations have the new fields shown in them. This problem requires major maintenance year after year.

What I wish

It would be REALLY nice if we could make new fields automatically hidden in all existing field configurations. We can't find a way to do that.

Alternatively, if we could have some sort of bulk hide operations that we could apply to some or all of the existing field configurations, that would be cool to.

We have JIRA 7.2.3, and we have Script Runner (which I figure has the power to do this if I only had a brain).

2 answers

This widget could not be displayed.

Jake,

I am having the same problem with 1200+ CFs and users are complaining that they are having a hard time finding the right field when they do a JQL search. I am still looking into a way to automatically hide the CF when it is created but I did write a script to hide all the CFs in a current projects Field Configuration. all you need to do is update the project key on line 15 and add the CF names that you want to be visible starting on line 17. 

 

Run this script in the ScriptRunner Script Console. It might take a while. Mine took 15 min. 

 

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.fields.FieldManager;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.issue.fields.layout.field.FieldLayoutManager;
import com.atlassian.jira.issue.fields.layout.field.FieldLayoutItem;
import com.atlassian.jira.issue.fields.layout.field.EditableFieldLayout;
import com.atlassian.jira.project.Project

//*** Get Needed Managers ***
FieldManager fieldManager = ComponentAccessor.getFieldManager();
FieldLayoutManager layoutManager = ComponentAccessor.getComponent(FieldLayoutManager)

//*** Initialize Variables ***
String result = "Done";
String projKey = "KEY"; //JIRA project Key
String[] usedFields = [
"CF1", //Custom Field Name
"CF2" //Custom Field Name
] as String[]

//Only look in the specified project
Project nextProject = ComponentAccessor.getProjectManager().getProjectObjByKey(projKey)

//Get all the Unique Field Layouts related to the project
def fLayouts = layoutManager.getUniqueFieldLayouts(nextProject)

//Loop throught the layouts
for (layout in fLayouts){

//Check if the layout name is not Null
if (layout.getName() != null){

//Get the ID of the layout
def layoutId = layout.getId();

//Loop through all the layout items (Custom Fields)
for (cf in layout.getFieldLayoutItems()){

//Check if Custom Field
boolean isCF = fieldManager.isCustomField(cf.getOrderableField().getId());
if(isCF == true){

//*** Lookup Field Layout ***
EditableFieldLayout editableLayout = layoutManager.getEditableFieldLayout(layoutId);

//*** Lookup Custom Field ***
CustomField field = fieldManager.getCustomField(cf.getOrderableField().getId());
FieldLayoutItem item = editableLayout.getFieldLayoutItem(field);

//Set visablilty of field
if(usedFields.contains(cf.getOrderableField().getName())){

//If item is hidden make it visible
if(item.isHidden() == true){
//*** Update Field Visability ***
editableLayout.show(item);
layoutManager.storeEditableFieldLayout(editableLayout)

}
}
else {
//*** Update Field Visability ***
editableLayout.hide(item);
layoutManager.storeEditableFieldLayout(editableLayout)
}
}

}
}
}
return result;

 

This widget could not be displayed.

1,000 custom fields is 900 beyond what is useful and sane.  I can't think of a way to justify that many custom fields, and there are memorable chunks of my career that have been "fixing fielditis"

In real life terms, the way JIRA is built does not expect this either, and it's not going to scale cleanly to do this.  You already mention some clever tricks I'd describe as "working around having too many fields", but even hiding them by default is not going to get around the scaling problems you have.

The best I could do with script runner is to run a console script which goes over the field configs and hides a field when an admin chooses to run it, but your admins are going to need to remember its there.

Yes, I started telling my management that we need to split our instance when I became the head admin of our Atlassian stuff (a year ago), but I don't think they want to take that seriously.

If there was a script we could use to specify a field, and have it hide that field on all the existing field configurations, that would be amazing! Is that something you could help us with, or is there a good place I could start to make such a script?

Suggest an answer

Log in or Sign up to answer
Atlassian Summit 2018

Meet the community IRL

Atlassian Summit is an excellent opportunity for in-person support, training, and networking.

Learn more
Community showcase
Published Jul 25, 2018 in Marketplace Apps

Jira Cloud and Bitbucket Cloud Integration with Microsoft Teams

One of the newest products in the Microsoft family - Microsoft Teams,  is a chat-based hub for teamwork that integrates all the people, content, and tools your team needs to be more engaged and ...

718 views 0 3
Read article

Atlassian User Groups

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

Find a group

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

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you