The starting point

In many JIRA instances, Javascript code associated to field configurations or scripts in other languages (as those used with Script Runner plugin, for example) refer to configuration objects by their internal IDs. This may cause problems when trying to transfer a configuration from one instance to another.

For example, imagine you are working on your DEV instance. You create a new custom field called "Field One" of type multiselect. This new custom field is created with an id of 10532. Then you create a piece of Javascript code associated to a field's description, so that it refers to this new custom field by its id, as in:

 <script type="text/javascript" charset="utf-8" id="someId">
...
document.getElementById("summary").value = "URGENT REQUEST - " + document.getElementById("customfield_10532").value + " - " + document.getElementById("customfield_10143").value;
...
</script>

Now you have finished developing and testing everything in DEV and you want to transfer all changes to PROD. You export the configuration with Project Configurator to an XML file and then import it in PROD. Everything goes fine: a field called "Field One" of type multiselect is created in PROD, and the description with the script is also transferred to PROD.

Problem

Project Configurator does not analyze and change arbitrary scripts that may be included in field descriptions, workflow extensions, etc. The script shown above is copied to PROD as it was in DEV. But when "Field One" is created in PROD it is assigned by JIRA a new ID that does not have to be the same as in DEV: 10532. In fact, it would be a very remarkable coincidence if it actually were the same ID!

This means the script in PROD will fail, as it references a custom field "customfield_10532" that does not exist, or even worse, it might reference a completely different custom field and silently produce wrong results.

Solution A

The best solution to this problem is referencing objects in scripts by name, instead of using IDs. See this page for detailed information of the attributes that Project Configurator uses for identifying items, those attributes are guaranteed to be preserved when the configuration is transferred to another instance.

Solution B

If solution A is not practical in your case, the other strategy is looking for ways to make the IDs be the same in DEV and PROD. You can achieve it if you perform changes following these steps:

1. Create in DEV all new items which will be required and may be referenced in scripts (for example, custom fields). Do not change scripts now.
2. Using Project Configurator, transfer these changes to PROD.
3. Copy PRODS database to DEV (for example, with a XML backup)
4. Now you have both in DEV and PROD all items that will be referenced in scripts and they have the same ID. Edit the scripts as needed in DEV.
5. Repeat step 2 and transfer the last batch of changes to PROD.