Project Configurator for Jira Server and DC

Configuration Export Errors

Project Configurator expects 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.

Common Causes

These are some of the scenarios you may find. After fixing them, the export process should run successfully.

Invalid Email Addresses

Exported email addresses must be valid. "Valid" here means it follows 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)

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

  • If an exported user has an email address

Users without email addresses are supported. This means a user without an email address will be correctly exported (or loaded if necessary), but if the user has an email address, it has to be valid. If you expect problems due to users with invalid email addresses, you can request the exporter to ignore these users or even to skip the export of all users, as explained in 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 and its app was later disabled or uninstalled. It can happen, too, 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.

Mandatory Data

As a general rule, Project Configurator expects 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 Jira would not let you leave empty, you should assume it is also required for successful export of that object within a project configuration. Some examples are as follows:

  • 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, priority, etc., this referred object must exist and be valid. Consider, for example, the case where the workflow is created with a reference to a custom field in a workflow post-function. If, later, that custom field is deleted or the app that defines its type is disabled, the workflow would be left with an invalid reference. That 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 in these cases:

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

  • If the name differs from names for other objects of the same kind only in the case of letters (for example issue type "Sub-task" vs "Sub-Task") or in surrounding whitespace (as in "My workflow scheme " vs "My workflow scheme")

If your Jira instance has objects like these, it is a good idea to rename them.

If troubles persist, please submit a request through our Support Portal. We will be very glad to help!