FAQ:Frequent Exporting Configurations Errors

Project Configurator expects that it will export a valid configuration in Jira. Some inconsistencies in the original configuration may make the export process finish with an error, instead of producing the expected XML file. Project Configurator's Object Dependencies report provides a visual mapping of how objects are used or referenced by other objects in your instance. Running this report before an export helps you identify any potential issues and take appropriate action before generating the export file. 

Common Causes

The following sections describe some common causes of errors in export files. After resolving them, the export process should run successfully.

Invalid email addresses

Exported email addresses must be valid, following the pattern, X@Z where X and Z are non-empty strings. Email addresses will be exported if:

• the project has an email address (as explained in Atlassian’s Configuring Email Notifications page).

• an email address is used as a notification receiver in the project’s notification scheme.

• an exported user has an email address.

Users without email addresses are supported. A user without an email address will be correctly exported (or imported if necessary). If you expect problems due to users with invalid email addresses, you can choose to ignore these users or skip the export of all users, as explained in the Users and Groups export options.

Custom fields without their app

IIn this case, the configuration contains custom fields whose type is defined in an app which is not enabled at the moment of export. This can happen if the custom field was created in an app that is later disabled or uninstalled. It can also happen if the custom field is created in an instance and its Jira database is later cloned to another instance where the app is not enabled. In both cases, enable the app before proceeding with an export.

Mandatory data

As a general rule, Project Configurator expects that an object contained in the configuration will have all mandatory fields and related objects. Consider the case where you were trying to create or modify that object through Jira's user interface. If there is a field or a related object that Jira would not let you leave empty, then you should assume that it is also required for the successful export of that object within a project configuration. Some examples are:

• An issue type screen scheme must have a default screen scheme
• A project must have a name and a leader

Objects used in workflow conditions, validators, or post-functions

If any workflow condition, validator, or post-function uses another object, such as a custom field, user, group, resolution, or priority, this referred object must exist and be valid. For example, if a workflow is created with a reference to a custom field in a workflow post-function and then that custom field is deleted or the app that defines its type is disabled, the workflow is left with an invalid reference. This would trigger an error when a configuration with that workflow is exported.

Object names that differ only in their case or with surrounding whitespace

Problems while exporting configurations may arise if:

• some of the objects being exported have names with leading or trailing whitespace, as in "My workflow scheme " or " My workflow scheme".

• the name differs from names for other objects of the same kind only by letter case, for example, issue type "Sub-task" vs "Sub-Task".

If your Jira instance has objects like these, rename them before proceeding with an export.

If troubles persist...

Please submit a request through our Support Portal. We will be very glad to help!