Handling project configurations
These items are not covered by this plugin:
- As the name is used to identify objects across different instances of JIRA, in general it is not supported having objects with duplicate names within the same scope (for example, several components with the same name in the same project).
Since v1.0.8 the plugin can export and load custom fields with duplicate field names as long as they have different types. The custom field type is identified by its key, including the plugin key, as in "com.atlassian.jira.plugin.system.customfieldtypes:datepicker". This means that several custom fields in the same instance with the same name and type will not be handled correctly. During export, they will be treated as if they were a single custom field. When importing, if the plugin finds more than one custom field in the target instance with the same name and type impacted by the new configuration, it will stop the import with a message like this:
Found more than one custom field with the same type and name: com.atlassian.jira.plugin.system.customfieldtypes:datepicker, Triage Date'
As the plugin would be unable to resolve which of those custom fields must receive the new configuration.
- Image files (icons) are not exported to or loaded from XML. The plugin will assign images to issue types, statuses, priorities, etc. with the same path they had in the original instance, but it is the user's job to make sure those images exist in the destination instance and are equivalent to the original images.
- The plugin does not export or load avatars for projects or users.
- If the configuration refers to custom field types, searchers, workflow conditions, post-functions or any other extension defined in a plugin, the user must ensure that those plugins are installed and enabled in the destination instance before loading the configuration.
- Other than the extensions mentioned here for some workflow conditions, validators and post-functions defined in some plugins, the support of JIRA Agile/JIRA Software and PCP-53, Project Configurator for JIRA is not able to export/import parts of the configuration that are specific of third party plugins. This is especially relevant for custom field types defined by other plugins.
- Notification templates are not exported to or loaded from the configuration XML file. It is the user responsibility to ensure that any notification template referred by an event type in the XML file, exist in the destination instance with the same name.
- Internationalization: the plugin is available only in English.
Items that must coincide in both JIRA instances.
- The conversion of a custom field default value to a string and back depends in some cases of the language settings (locale). This may cause problems if a configuration with default values for custom fields is exported from a JIRA instance and loaded into another instance with a different default language. To avoid them, ensure that the original instance has the same default language as the destination.
- The same applies to the formats used to convert dates and times to strings and back (see "Configuring date picker formats" in this page). They must be the same in both instances.
- Some global settings must be the same in both instances of JIRA:
- Time tracking
- Allow unassigned issues
These settings impact the presence of some system fields and whether some attributes of a project are mandatory or not. If they are different in the source and destination instance, the exported configuration may be invalid in the target instance.
Importing complete projects
Import of complete projects (i.e their configuration, issue data and attachments) is subject to the restrictions described in this page, especially:
- JIRA versions of the source and target instances must be identical.
- If the source instance had any custom field plugins installed when the backup file was created, and the custom field was used in any of the exported projects, then the target instance of JIRA must have the same version of the plugins installed
- Your instance of JIRA will be locked out during the actual data import (not during the validations), so please ensure that your instance does not need to be accessible during this time.
- The timezone of the source instance must be the same as that of the target instance. Otherwise, the import would be affected by JRA-26039 and imported dates would not be correct.