JIRA Agile Knowledge Base
Space shortcuts

JIRA Agile Documentation
Jira Agile 6.3
GreenHopper 6.2
GreenHopper 6.1
More...

Agile Knowledge Base Resources
Child pages
  • How to unlock a Locked field
Skip to end of metadata
Go to start of metadata

Platform Notice: Server and Data Center Only. This article only applies to Atlassian products on the server and data center platforms.

Symptoms

In some cases you will need to unlock a Locked JIRA Agile field.

Cause

These fields are locked to prevent accidental changes which can subsequently break the operation of JIRA Agile. Due to certain problems within JIRA and JIRA Agile, sometimes the fields need to be manually unlocked so they can be altered.

Resolution

  1. Run the following query via database to determine the JIRA Agile custom field IDs

    SELECT id,customfieldtypekey,cfname from customfield where customfieldtypekey like 'com.pyxis.greenhopper.jira%';

    It should return a result like the following:

      id   |                         customfieldtypekey                         |         cfname
-------+--------------------------------------------------------------------+-------------------------
 10204 | com.pyxis.greenhopper.jira:gh-global-rank                          | Rank
 10205 | com.pyxis.greenhopper.jira:gh-sprint                               | Sprint
 10206 | com.pyxis.greenhopper.jira:gh-epic-link                            | Epic Link
 10207 | com.pyxis.greenhopper.jira:gh-epic-label                           | Epic Name
 10208 | com.pyxis.greenhopper.jira:gh-epic-status                          | Epic Status
 10209 | com.pyxis.greenhopper.jira:gh-epic-color                           | Epic Colour
 10211 | com.pyxis.greenhopper.jira:greenhopper-releasedmultiversionhistory | Release Version History

  2. You will have to match the id of the field you want to unlock with the according entry in managedconfigurationitem table's item_id column.

    SELECT * from managedconfigurationitem;
      id   |      item_id      |  item_type   | managed | access_level |                       source                       |      description_key
-------+-------------------+--------------+---------+--------------+----------------------------------------------------+----------------------------
 10000 | customfield_10204 | CUSTOM_FIELD | true    | LOCKED       | com.pyxis.greenhopper.jira:reference-select-locked | gh.customfield.locked.desc
 10001 | customfield_10205 | CUSTOM_FIELD | true    | LOCKED       | com.pyxis.greenhopper.jira:reference-select-locked | gh.customfield.locked.desc
 10002 | customfield_10206 | CUSTOM_FIELD | true    | LOCKED       | com.pyxis.greenhopper.jira:reference-select-locked | gh.customfield.locked.desc
 10003 | customfield_10207 | CUSTOM_FIELD | true    | LOCKED       | com.pyxis.greenhopper.jira:reference-select-locked | gh.customfield.locked.desc
 10004 | customfield_10208 | CUSTOM_FIELD | true    | LOCKED       | com.pyxis.greenhopper.jira:reference-select-locked | gh.customfield.locked.desc
 10005 | customfield_10209 | CUSTOM_FIELD | true    | LOCKED       | com.pyxis.greenhopper.jira:reference-select-locked | gh.customfield.locked.desc

  3. You will need to set the managed column to false of any field you want to unlock. For example, the below will unlock Epic Status and Epic Colour:

    UPDATE managedconfigurationitem set managed='false' where item_id in ('customfield_11208','customfield_11209');

    Note: After the above change the 'access_level' column will remain with the 'LOCKED' value, but the custom fields will be unlocked from the UI.

  4. Make the required changes to the fields.

  5. Lock the fields that were unlocked by setting the managed column to true. For example, the below will lock Epic Status and Epic Colour:

     UPDATE managedconfigurationitem set managed='true' where item_id in ('customfield_11208','customfield_11209');

These fields will be locked again on startup by automated tasks within plugins such as JIRA Agile.

Help us improve!

Unknown macro: {kbsurvey}

16 Comments

  1. MattS

    Do you need to restart JIRA to pick up the database change? This change could probably be done better using Script Runner script to avoid a restart.

    1. MattS

      https://answers.atlassian.com/questions/253056/unlock-a-field-with-script-runner# has a working script to do this:

       

      1
      2
      3
      4
      5
      6
      7
      8
      9
      10
      11
      12
      13
      14
      15
      16
      import com.atlassian.jira.component.ComponentAccessor
      import com.atlassian.jira.config.managedconfiguration.ManagedConfigurationItemService
      import com.atlassian.jira.issue.CustomFieldManager
       
      ManagedConfigurationItemService managedConfigurationItemService = ComponentAccessor.getComponent(ManagedConfigurationItemService)
      CustomFieldManager customFieldManager = ComponentAccessor.getCustomFieldManager()
       
      def cf = customFieldManager.getCustomFieldObjectByName('My Customfield')
       
      if (cf) {
          def mci = managedConfigurationItemService.getManagedCustomField(cf)
          if (mci) {
              managedConfigurationItemService.removeManagedConfigurationItem(mci)
          }
          // Uncomment to delete the custom field as well
      // customFieldManager.removeCustomField(cf)
      }

  2. krishk

    This is what worked for me in PostGreSQL:

    Single quotes at both places - for 'false' and 'customfield_11208' - example below - 

    UPDATE managedconfigurationitem set managed='false' where item_id in ('customfield_11193');

  3. Joe Cross

    How can you do this for an onDemand instance?  I hope Atlassian didn't rename the "Epic Colour" field, thereby creating an integration blocker, without any workaround...

    1. itse

      Joe, you won't be able to do this yourself. To get help with that you should contact support @ support.atlassian.com to get help with that.

  4. agouaux

    So why are these locked in the first place?

    1. Dave C

      The page has been updated to specify why. (smile)

  5. Evgeny Minkevich

    Can there be undesirable side effects of unlocking them? Surely there was a reason for locking them in the first place a agouaux has mentioned?

    1. Dave C

      Yes, users can go and make changes to things like contexts or custom field configurations that will have the unintended effect of breaking JIRA Agile - this is why we locked them in the first place. Unfortunately due to some unforeseen reasons (namely bugs) they sometimes need to be unlocked.

      1. MattS

        "namely bugs" - good to see a clear statement, thanks. Just for laughs here's a list of euphemisms from a book I wrote a while ago:

        "It's hard work to sell products that have known bugs, faults, or failures, but products with unresolved issues, anomalies, artifacts, or even potential defects somehow sound better to prospective customers. You may even come across some products with design side effects! Be careful when you choose your own euphemisms, making sure that everyone knows exactly what the words mean for your project. Also, note that the terms defect and incident can have unforeseen legal consequences. For simplicity, the term used in the rest of this book is the good old Anglo-Saxon bug from the Anglo-Saxon budda, meaning "beetle" ( http://alt-usage-english.org). "

      2. Stephen Welsh

        Yes ...bugs in Agile ...so over all this ...

        Does the re-indexing ever complete?  Or should I be having unscheduled downtime?

         

        Steve

        1. Dave C

          Steve this symptom doesn't sound related to locked fields, can you please raise a support request on support.atlassian.com and we can take a look.

  6. René Bodack

    MattS thanks for the convenient ScriptRunner solution. 

    Here's a follow-up script for anyone who wants to re-lock the field after the necessary changes are made:

    import com.atlassian.jira.component.ComponentAccessor
import com.atlassian.jira.config.managedconfiguration.ConfigurationItemAccessLevel
import com.atlassian.jira.config.managedconfiguration.ManagedConfigurationItemService
import com.atlassian.jira.issue.CustomFieldManager
ManagedConfigurationItemService managedConfigurationItemService = ComponentAccessor.getComponent(ManagedConfigurationItemService)
CustomFieldManager customFieldManager = ComponentAccessor.getCustomFieldManager()

def cf = customFieldManager.getCustomFieldObjectByName('My Customfield')

if (cf) {
    def mci = managedConfigurationItemService.getManagedCustomField(cf)
    if (mci) {
        def managedConfigurationItemBuilder = mci.newBuilder();
        def updatedMci = managedConfigurationItemBuilder
            .setManaged(true)
            .setConfigurationItemAccessLevel(ConfigurationItemAccessLevel.LOCKED)
            .build();
        managedConfigurationItemService.updateManagedConfigurationItem(updatedMci);
    }
}

    1. MattS

      Thank  Henning Tietgens for that

  7. Brian Bagent

    How do I "unrequire" the description field when creating a new ticket?  When I go to the field configuration editor, the description field is not showing to be required, yet I can't create a ticket without adding text to the description field.

    It's really confusing because I have a couple projects where all configurations are the same except the workflows and workflow schemes, but entering text into the description field is optional when creating new tickets.

  8. Darren Warner

    I had to unlock 'Epic Colour' and change it to 'Epic Color' so that I could import a project from another instance. You use this field as an example here as well as elsewhere on this Confluence, which tells me this has been one of the common reasons why users need to unlock fields in the first place - it seems that this name must have been changed in a recent version of Agile.

    I'm in the U.S. and would like to use the U.S. spelling. Is it safe for me to leave it as 'Epic Color', or is this going to break my Agile installation?

    FWIW: My internationalization settings are correct on both instances (not changed, defaulted to U.S.)