Issues migrating projects in Jira Server using add-on Project Configurator

[BenK]

Hi there. I've been having an issue for more than a week now trying to migrate a fairly old legacy project to a new environment using Project Configurator between two Jira Server environments.

Just to give the specifics:

• New destination Jira Server version: 7.12.1
• Old Jira Server version: 7.12.1, upgraded from a clone of a 6.4.4 environment
• Project Configurator Version: 3.1.10

When I fire off the migration, about 260-odd of 1200 issues will import fine but then the import will fall over. From the import trace I will get the following repeated for a series of issues until the JRE just gives up the ghost:

ERROR 16:43:31,576 Unable to create issue with key 'AA-123'.
com.atlassian.jira.external.ExternalException: Unable to create issue: Title of Issue Here
at com.atlassian.jira.external.ExternalUtils.createIssue(ExternalUtils.java:228)
at com.atlassian.jira.imports.project.DefaultProjectImportPersister.createIssue(DefaultProjectImportPersister.java:145)
at com.atlassian.jira.imports.project.handler.IssuePersisterHandler$1.run(IssuePersisterHandler.java:71)
at com.atlassian.jira.util.concurrent.BoundedExecutor$1.run(BoundedExecutor.java:50)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
at java.lang.Thread.run(Thread.java:748)
Caused by: com.atlassian.jira.exception.CreateException: com.atlassian.jira.workflow.WorkflowException: Unable to find field 'customfield_10040'
at com.atlassian.jira.issue.managers.DefaultIssueManager.createIssue(DefaultIssueManager.java:519)
at com.atlassian.jira.issue.managers.RequestCachingIssueManager.createIssue(RequestCachingIssueManager.java:204)
at com.atlassian.jira.external.ExternalUtils.createIssue(ExternalUtils.java:220)
... 6 more
Caused by: com.atlassian.jira.workflow.WorkflowException: Unable to find field 'customfield_10040'
at com.atlassian.jira.workflow.OSWorkflowManager.createIssue(OSWorkflowManager.java:768)
at com.atlassian.jira.issue.managers.DefaultIssueManager.createIssue(DefaultIssueManager.java:510)
... 8 more
Caused by: java.lang.IllegalArgumentException: Unable to find field 'customfield_10040'
at com.googlecode.jsu.util.WorkflowUtils.getFieldFromKey(WorkflowUtils.java:148)
at com.googlecode.jsu.workflow.function.CopyValueFromOtherFieldPostFunction.executeFunction(CopyValueFromOtherFieldPostFunction.java:46)
at com.googlecode.jsu.workflow.function.AbstractPreserveChangesPostFunction.execute(AbstractPreserveChangesPostFunction.java:54)
at com.opensymphony.workflow.AbstractWorkflow.executeFunction(AbstractWorkflow.java:1014)
at com.opensymphony.workflow.AbstractWorkflow.transitionWorkflow(AbstractWorkflow.java:1407)
at com.opensymphony.workflow.AbstractWorkflow.initialize(AbstractWorkflow.java:606)
at com.atlassian.jira.workflow.OSWorkflowManager.createIssue(OSWorkflowManager.java:742)
... 9 more

Clearly the key issue here is some strange behaviour with this custom field referenced as customfield_10040.

I figured I'd done my homework on this at this point. ID 10040 refers to a drop-down user picker custom field we've called "Attacher".

I found from previous imports that a custom field of the same name and type as the one referenced by that ID in the old environment had been created by someone else in the new environment, but after determining that field wasn't being used by anything I deleted it to avoid conflicts.

Now at this point, I'm very lost. I've tried every possible permutation of exporting project ZIP files from the old environment. In the end to avoid other problems I've chosen to not export User options, Group options, Filters, Dashboards or Agile Boards. I've selected "Automatic" for "Attachment migration" so they're in the ZIP file and I've set "Custom Field Options" to "Only those used in projects".

On the receiving end I run a full import simulation and confirm that with the options I'm selecting Configurator is creating new custom fields as required. One of the new fields created is the "Attacher" field I referenced earlier.

It does seem to be creating "Attacher" with a different custom field Id. This might be significant, but isn't the whole point of Configurator that it's supposed to handle this kind of thing and re-map the import data instead of just falling over?

Any insight would be greatly appreciated, thanks in advance.

[Kristian Walker _Adaptavist_ · Accepted solution]

Hi BenK,

Thank you for your question

I have reviewed your attached error shown above, and can confirm the reason why the issue data cannot be imported is because there is a post function on the *create* transition in the workflow which is failing and the *built-in Jira data import functionality* which *Project Configurator* uses to import in the issue data runs the *create* transition in the workflow to create an issue and if a post function fails then it will not create the issue.

This post function is of the type *Copy Value from other field* and is provided by the *Jira Suite Utilities* plugin which is documented [here|https://marketplace.atlassian.com/apps/5048/jsu-automation-suite-for-jira-workflows?hosting=server&tab=overview].

This means that to work around this issue you should remove this post function from the workflow in the *target* instance before re-running the import, ensuring you skip importing the workflows otherwise *Project Configurator* will re-add in the post function during the configuration import.

I hope this information helps.

Regards,

Kristian

[BenK]

Hi there Kristian

Thank you for your assistance with this. I am still in the process of working out the specifics to resolve every post action in the workflows I need to update (a bit like pulling weeds) but it's definitely using using "Copy Value from other field" as well as "Clear field value" from an old version of JSU.

This information is a huge help, thank you.

Regards

Ben

[Fadoua · Accepted solution]

@BenK just making sure is the plugin version the same in both environments?

[BenK]

Correct, double checked :-)

[Fadoua]

@BenK  Can you please try one more time to add the field behind your miseries and see if it will work? I know you mentioned that you tried and then removed it.

Let's try it one more time. Run your indexing, in the meantime I will take a quick glance at the plugin as I have a deep experience with Configuration Manager.

[BenK]

@Fadoua thanks for your time, I really don't want to waste too much of your time on this. I've performed a re-index of the project on the originating server, and as for the new server, It's a bit like pulling weeds I've comepltely deleted the imported issues, project, field config schemes, field configs, custom fields (including the "Attacher" field that gets created with each import attempt), issue type screen schemes, screen schemes and screens associated with the project for as clean a start as I can get.

Interestingly (and I really don't want to set anyone off on a red herring here) but I think I might have been a bit more thorough in removing the cruft of previous import attempts this time. The data import fell over this time because Project Configurator complained that "Attacher" was as follows:

This custom field relies on a plugin that is not installed. Please install the plugin "com.atlassian.jira.plugin.system.customfieldtypes" before running the import again or recalculating.

Weirdly enough though, this field in the originating environment isn't relying on any special plugins. It's just a user-picker drop-down list. Just thought it might worth mentioning as the problems might be deeper than Configurator after all.

[Fadoua]

@BenK you never bother us, we are here to help. I am glad @Kristian Walker _Adaptavist_ they are more knowledgeable since they are the plugin developers.

Thanks Kristian!

Best,

Fadoua

[BenK]

@Fadoua thanks for your assistance with this, appreciated. I believe I've been pointed in the right direction with this now.

Cheers

Ben