Project Configurator for Jira Server and DC

Configuration Export Errors

Project Configurator expects to export a valid configuration in Jira. Inconsistencies in the original configuration of your instance may cause the export process to finish with an error instead of generating the expected XML file. The 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. The following sections describe some common causes of errors in export files.

If you continue to encounter errors after identifying the cause and resolving the issue in your source instance, you can consult our Project Configurator Knowledge Base for searchable how-to and troubleshooting articles. If troubles persist, please submit a request through our Support Portal. We will be very glad to help!

Common Causes

The following are some common scenarios that cause issues with generating your XML file. 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

In 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.

Project Configurator generally expects an object contained in the configuration will have all the mandatory fields and related objects. Therefore, when creating or modifying an object through Jira’s user interface, if there is a field or a related object that is mandatory, you should assume it is also required for the successful export of that object within a project configuration. For example:

  • 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".

  • If 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.