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.
- Project Configurator for JIRA is able to export/import parts of the configuration that are specific of third party applications or plugins (this is especially relevant for custom field types defined by other plugins) only in these cases:
- the extensions mentioned here for some workflow conditions, validators and post-functions defined in some plugins
- the support of JIRA Agile/JIRA Software (this means Scrum or Kanban boards are migrated)
- Jira Service Desk (you can configure a service desk project in one instance and move that configuration to another instance)
- Default values for fields of type com.atlassian.jira.toolkit:message. as explained in PCDEV-180
- 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.
Applications/plugins supported for data transfer
Currently, data transfer is supported for these applications:
- Jira Software. Sprint and ranking data (on JIRA 7).
- Jira Service Desk. Starting with version 2.3.0-J7 of Project Configurator.
Data of any plugin that implements the extension points defined by Atlassian here will also be handled. Also, any custom field values belonging to custom fields whose types are defined in a plugin, will be imported if that custom field type implements the interface com.atlassian.jira.imports.project.customfield.ProjectImportableCustomField.