Now you have finished developing and testing everything in theDEVinstance, and you want to transfer all changes toPROD. You export the configuration, using Project Configurator, to an XML file, then import it intoPROD. Everything goes correctly: a field calledField Oneof type multiselect is created inPROD, and the description with the script is also transferred toPROD.
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 toPRODas it was inDEV. But whenField Oneis created inPROD, it is assigned a new ID by Jira that does not have to be the same as inDEV: 10532. In fact, it would be a very remarkable coincidence if it actually were the same ID.
This means the script inPRODwill 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. SeeHow Project Configurator Worksfor detailed information on the attributes Project Configurator uses for identifying 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 inDEVandPROD. You can achieve this if you perform changes following these steps:
Create all new items inDEVwhich will be required and may be referenced in scripts (for example, custom fields). Do not change scripts now.
Transfer these changes toPROD, using Project Configurator.
CopyPROD’sdatabase to DEV (for example, with a XML backup)
Edit the scripts as needed inDEV. Now that you have both inDEVandPROD, all items that will be referenced in scripts, and they have the same ID.
Repeat step 2 and transfer the last set of changes toPROD.