Migrating "Epic status" is not locked on source (Jira v8.12.3) but locked on destination (v9.2)

[Tim C]

Hi,

We've got a Jira server migration challenge which not been able to resolve.

The "Epic Status" field is not showing as a locked field on source server (Jira v8.12.3) and is just included as a standard customfield in the database.

The same "Epic Status" field is locked on destination server (Jira v9.2) and is included in the "managedconfigurationitem" database table (as expected).

The only instructions I've seen to be able to unlock/lock a customfield assumes that it already exists in the "managedconfigurationitem" database table.

Anyone know if/how we can safely add a record into this "managedconfigurationitem" table to make the customfield show as locked field (on the source server) ???  

Hopefully, the 3rd party migration application ("project configuration for jira") will then ignore it (as a system field).

Any feedback or advice would be welcomed - as this issue has become a complete blocker (for the migration).

Thanks in advance.

[Nic Brough -Adaptavist- · Accepted solution]

The content of that table is not too obtuse to work out, unlike most of the rest of a Jira database, and it's ok to insert data into it, but you will still need to check and possibly update the sequence table.

As usual, you will need Jira offline while you run the SQL to insert the data, and I'd recommend re-indexing after you bring it back up.

The standard content is documented directly at https://confluence.atlassian.com/jirakb/unlock-a-locked-jira-software-custom-field-779158866.html 

Before you lock the field though, I would recommend

• Working out why your admins unlocked it and what changes they made to the configuration of it that the lock was preventing them doing
• Undo it.  The locks are there for a reason - to stop you misconfiguring the fields.  You are going to have problems migrating your data anywhere if you've got misconfigured fields
• Check that your Epic-name field really is of the right type - is it definitely a  com.pyxis.greenhopper.jira:gh-epic-status field in the customfield table?
• Check what numbers there are in managedconfigurationitem table.  When you insert a row into it, you are going to need to use e that fits the pattern of usage (basically, the number has to be 10000 or above, and unique). The ID number in this type of table always goes up, and is stored in a sequence table, so if you're adding to the end of the table, you need to increase the sequence counter.  However, because they always go up, and are not actually used as a sequence, they often have gaps which you can fill. 

If, for example, you have a table with 10009, 10010, 10019, 10020, 10021, then instead of having to faff around with the sequence table to add your row with an id of 10022, just use an id in the gap - anything between 10011 and 10019 in my example.

[Tim C]

Hi @Nic Brough -Adaptavist- 

Thanks for the reply & feedback.   

Actually, as far as I can tell, I don't think the "Epic Status" field was previously locked where it doesn't appear in the manageconfigurationitem table - so it wasn't as simple as changing the "manage = true/false" flag (as indicated in the article).

"managedconfigurationitem" table:
10000 | customfield_10101 | CUSTOM_FIELD | true | LOCKED
10001 | customfield_10102 | CUSTOM_FIELD | true | LOCKED
10002 | customfield_10100 | CUSTOM_FIELD | true | LOCKED
10003 | customfield_10103 | CUSTOM_FIELD | true | LOCKED
10004 | customfield_10105 | CUSTOM_FIELD | true | LOCKED

"customfields" table:
10100 | | com.pyxis.greenhopper.jira:gh-global-rank
10101 | | com.pyxis.greenhopper.jira:gh-sprint
10102 | | com.pyxis.greenhopper.jira:gh-epic-link
10103 | | com.pyxis.greenhopper.jira:gh-epic-label
10104 | | com.pyxis.greenhopper.jira:gh-epic-status
10105 | | com.pyxis.greenhopper.jira:gh-epic-color

The "10104" is only one of these greenhopper fields that's not already included in the manageconfigurationitem table.

Anyway, as you say, hopefully it's as simple as adding a new entry in the "managedconfigurationitem" table (with a unique sequence ID).  There's lots of gaps later in the same table - so thanks for explaining they don't do anything important.

Thanks,

Tim

[Nic Brough -Adaptavist-]

It will have been locked in the past, unless you've been inheriting and maybe upgrading a very old Jira with a very old version of "Agile" (now "Jira Software") on it, as Jira Software has has locked the fields as it was installed for years.

The unlocking process is actually the removal of the line from the table, so I expect that's how your old admin unlocked it - deleted the line from the table completely!

But, yes, it all looks good to me, you've found a gap you can use for the new line, your data all matches, and I expect your insert will fix all of it (It might even not need Jira to be offline when you do it, but I can't tell you to take that risk, I'm not 100% sure)

[Tim C]

For information, in case anyone else runs into this same issue & finds this query ...

The unlocked "epic status" field on the source server didn't have any default value set (i.e. "none") - however, the locked "epic status" field on the target server had a default value of "to do".

For us, this issue was resolved by unlocking the field (by making database change to set "managed" to "false" for field entry in the "managedconfigurationitem" table) and removing the "default" value on target server (i.e. setting default to "none" same as on source server).

The "project configurator for jira" application - then could link these customfields & synchronize the project data accordingly.