Child pages
  • How to unlock a Locked field
Skip to end of metadata
Go to start of metadata

This article only applies to Atlassian's server products. Learn more about the differences between cloud and server.

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. 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. 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. 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. 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. 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. So why are these locked in the first place?

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

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

    1. 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. "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. Yes ...bugs in Agile ...so over all this ...

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

         

        Steve

        1. 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. 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);
        }
    }
  7. 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. 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.)