Project Configurator for Jira Server and DC

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).

    1. 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.

  2. 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.

  3. The app does not export or load avatars for projects or users.

  4. 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.

  5. 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

  6. 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.

  7. 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.

  • It is recommended that the Jira versions of the source and target instances be the same. Project Configurator allows you to import data from an earlier version of Jira, however, the greater the differences between versions, the greater the possibility of unexpected results or inconsistencies. If your versions are not the same, ensure that the target instance has the more recent Jira version as differences between the two could cause the data import run by the built-in Jira data import functionality to fail.

  • 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.