Limitations of Project Configurator

Handling Project Configurations

These items are not covered by this app:

1. 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 app 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 app 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 app 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 app would be unable to resolve which of those custom fields must receive the new configuration.

1. Image files (icons) are not exported to or loaded from XML. The app 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.
2. The app does not export or load avatars for projects or users.
3. If the configuration refers to custom field types, searchers, workflow conditions, post-functions or any other extension defined in an app, the user must ensure that those apps are installed and enabled in the destination instance before loading the configuration.
4.  Project Configurator for Jira is able to export/import parts of the configuration that are specific of third-party applications or apps (this is especially relevant for custom field types defined by other apps) only in these cases:
   
   • the extensions listed for some workflow conditions, validators and post-functions defined in some apps
   • 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
5. 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.
6. Internationalization: the app 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 and Time Formats). 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 Atlassian's Restoring a Project From Backup 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 apps 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 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 app that implements the extension points defined in Atlassian's Extending the Jira Import Plugin page will also be handled. Also, any custom field values belonging to custom fields whose types are defined in an app will be imported if that custom field type implements the interface "com.atlassian.jira.imports.project.customfield.ProjectImportableCustomField".

The app supports conditions, validators and post-functions defined in standard Jira plus the following apps:

• Jira Suite Utilities
• Jira Misc Workflow Extension
• Customware Jira Utilities
• Script Runner (only for canned scripts included with this app)
• Jira Workflow Toolbox (new since version 1.3.2)