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.
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 that 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 here)
- 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. This means a user without 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 export of all users.
Custom fields without their plugin
In this case the configuration contains custom fields whose type is defined in a plugin which is not enabled at the moment of export. This can happen if the custom field was created and later its plugin was disabled or uninstalled. It can happen too if the custom field is created in an instance and later its JIRA database is cloned to another instance where the plugin is not enabled.
As a general rule, Project Configurator expects that any 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 related object that JIRA would not let you leave empty, then you should assume that it is also required for 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, 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 plugin 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 which will 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.