Skip to end of metadata
Go to start of metadata

Hidden Fields custom fields are removed from ScriptRunner for Jira Server/Data Center. Hidden fields will no longer be available in your instance. However, all the hidden fields configuration and data will still exist in the database.

Migration

There are two options for dealing with hidden fields:

  • You would have been using these fields because you didn’t want the contents visible to all users all of the time. Now, the contents will no longer be hidden by the behaviours applied to them in the View Issue screen (these behaviours will hide fields in the Edit Issue screen). We recommend you investigate the Atlassian Marketplace for other apps that provide the ability to hide fields in the View Issue screen.

  • The recommended approach is to convert them to regular short text or long text fields. To convert hidden fields to regular fields, go to ScriptRunner→Script Console, and execute the following script:

import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.issue.fields.layout.field.FieldLayoutManager
import org.ofbiz.core.entity.DelegatorInterface
import org.ofbiz.core.entity.EntityExpr
import org.ofbiz.core.entity.EntityOperator

def delegatorInterface = ComponentAccessor.getComponent(DelegatorInterface)
def customFieldManager = ComponentAccessor.customFieldManager
def fieldLayoutManager = ComponentAccessor.getComponent(FieldLayoutManager)

def replacementFieldTypes = [
    'com.onresolve.jira.groovy.groovyrunner:hideable-textfield': 'com.atlassian.jira.plugin.system.customfieldtypes:textfield',
    'com.onresolve.jira.groovy.groovyrunner:hideable-textarea' : 'com.atlassian.jira.plugin.system.customfieldtypes:textarea',
]

delegatorInterface.findByOr('CustomField', replacementFieldTypes.keySet().collect {
    new EntityExpr('customfieldtypekey', EntityOperator.EQUALS, it)
}).each {
    def replacementType = replacementFieldTypes[it.getString('customfieldtypekey')]
    log.warn ("Converting '${it.getString('name')}' to $replacementType.")
    it.put('customfieldtypekey', replacementType)
    delegatorInterface.store(it, true)
}

fieldLayoutManager.refresh()
customFieldManager.clear()

"Fields converted"


This is safe to re-run if you are not sure it’s been done before, and is the recommended approach to convert these fields to regular fields.

We recommend users change the custom field type of all hidden fields before upgrading to ScriptRunner for Jira 6.0 and above.

If you use these fields on Jira Service Desk, there is the possibility that the fields of these types will be removed from the screen. There is a bug in Jira Service Desk such that if a user opens a request type which contains fields that are currently not present in the system, they will be permanently removed from the database table that details which fields are part of this request type. If this happens you will need to add them back to the relevant request types.

This problem can be avoided by following this migration procedure before updating.

Alternative Method

Alternatively, you can follow Atlassian guidelines for changing a field type. However this requires database access, and a Jira restart. If changing custom field type via the database, use the following type keys for what to search for and its replacement:

Old Key

Replacement Key

com.onresolve.jira.groovy.groovyrunner:hideable-textfield


com.atlassian.jira.plugin.system.customfieldtypes:textfield

com.onresolve.jira.groovy.groovyrunner:hideable-textarea


com.atlassian.jira.plugin.system.customfieldtypes:textarea

Rationale

We are sorry for the inconvenience this will cause you if you use these fields, as we almost never remove features.

These fields were removed as there is no maintainable way to truly hide the contents of a field which covers all the various ways that a user might see it. Not just in the view issue screen, but also: in the issue navigator, in the history tab, in the REST API, when exporting to CSV, Word, PDF.

Rather than handle most of these cases but not all, at least not in a maintainable way across all Jira versions, we took the decision that it was more honest to not support these anymore, rather than risk a customer accidentally exposing data to a user that they thought was not possible.

  • No labels