In many Jira instances, JavaScript code associated with field configurations or scripts in other languages—as languages— as those used with the ScriptRunner app—refer app — refers 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 your DEV instance instance. You create a new custom field called called Field One of type multiselect of type multi-select. This new custom field is created with an ID of 10532. You then create a piece of Javascript code associated with a field’s description, so it refers to this new custom field by its ID, as in the following:
...
<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 that you have finished developing and testing everything in the DEV instance, and you want to transfer all changes to to PROD. You export the configuration, using Project Configurator, to an XML file, then import it into into PROD. Everything goes correctly: a field called called Field One of type multiselect of type multi-select is created in in PROD, and the description with the script is also transferred to 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 to PROD as as it was in in DEV. But when when Field One is is created in in PROD, it is assigned a new ID by Jira that does not have to be the same as in in DEV: 10532. In fact, it would be a very remarkable coincidence if it they actually were had the same ID.
This means the script in in PROD will will fail, as it references a custom field "customfield_10532" that does not exist. Even worse, the script might reference a completely different custom field and silently produce wrong results.
...
The best solution to this problem is referencing objects in scripts by name instead of using IDs. See See How Project Configurator Works for for detailed information on the attributes Project Configurator uses for identifying to identify items. Those attributes are guaranteed to be preserved when the configuration is transferred to another instance.
...
If solution A is not practical in your case, the other strategy is looking for ways to make the IDs the same in DEV and in DEV and PROD. You can achieve this if you perform changes following these steps:
Create all new items
...
in DEV
...
that will be required and may be referenced in scripts (for example, custom fields). Do not change scripts now.
Transfer these changes
...
to PROD
...
using Project Configurator.
...
Copy PROD’s
...
database to DEV (for example, with
...
an XML backup)
Edit the scripts as needed
...
in DEV. Now that you have both
...
in DEV and PROD, all items that will be referenced in scripts
...
and they have the same ID.
Repeat step 2 and transfer the last set of changes
...
to PROD.