On this page:
...
In order to fix the configurations of the recently added/merged custom field, an edit of each one and replacing the references by ID with the new value is needed. CMJ does support "Persist deployed snapshot to current system native ID mappings". This option can be enabled from the General Settings page. Once enabled, every deployment will generate a mapping file. The last row of the audit log will contain a text similar to this: "Persisted snapshot to target native ID mappings in file ...\target\container\tomcat8x\cargo-jira-home\temp\deploymentSnapshotToTargetNativeIdMap_BotronSoft_8998591105496969158.json". This file contains a map for each configuration item with the ID from source and target. The rows that explain the custom fields are as follows:
| Code Block |
|---|
"JiraCustomField": {
"customfield_10008": "customfield_10016",
"customfield_10009": "customfield_10017",
...
|
The key (first ID) is the id on the source, the value (second ID) is the value on target. This mapping let us know which is the new ID without having to look at the configuration or the DB.
The configuration of customfield_10017 (Calculated Number Field) should be changed to refer customfield_10016 instead of customfield_10008.
This can be done also automatically, by some script, that uses the JSON mapping and Jira's REST API.
Avoid referencing custom fields by native id
If the configurations of the calculated/scripted fields (and other configuration elements like Post Functions, Conditions, etc) references to other elements by their name instead of native ID will allow CMJ to migrate their configuration without having to alter the scripted part after each deployment. In the example given in this article the following line:
issue.get("customfield_10008");
could be replaced with:
issue.get("Number Field");
...