Annual Documentation Survey
This section explains the operating principles of Project Configurator.
In order to export or import complete projects (i.e their configuration, issue data and attachments) Project Configurator follows internally the process described in Moving a project to another instance (with versions 1.X of Project Configurator), with one difference that improves its performance: the XML backup excludes data for projects that are not exported.
You can view the export and import of complete projects in version 2.X and later, as a wrapper that automates that process for the user, so that it provides a simpler, more convenient solution and saving a large amount of work. This has some implications:
In order to identify corresponding objects across different instances of Jira, the app relies on the name of objects, with a few exceptions:
The object context is also considered for those objects that are part or children of another object. For example, options are identified by their name only among the options existing within a custom field configuration.
When loading a configuration, the app will apply the minimum set of changes that will make the configuration in Jira equivalent to the configuration described in the XML file. This means that:
When exporting a project configuration to XML, the app exports the project configuration, including the configuration of:
The objective is that the configuration file is self-sufficient, in the sense that it contains all necessary information to replicate the project in another instance of Jira.
The exported XML file is always ordered following the same rules. The goal is to facilitate comparison of configuration files so that they can be used as a tool for detecting changes to configurations in Jira.
|Parent element||Children elements||Order by|
|permissionScheme||permissionHolder||permission, holder.assignee, holder.group, holder.groupField, holder.projectLead, holder.projectRole, holder.reporter, holder.user, holder.userField|
|issueSecurityScheme||permission||level, permittedTo.assignee, permittedTo.group, permittedTo.groupField, permittedTo.projectLead, permittedTo.projectRole, permittedTo.reporter, permittedTo.user, permittedTo.userField|
|notificationSchemeType||notificationReceiver||event, receiver.allWatchers, receiver.assignee, receiver.componentLead, receiver.currentUser, receiver.emailAddress, receiver.group, receiver.groupField, receiver.projectLead, receiver.projectRole, receiver.reporter, receiver.user, receiver.userField|
EXCEPTION: <singularValue> is not guaranteed to be ordered, instead, they maintain the order they have in Jira, as it is relevant in some cases (for example in cascade select custom fields)
|columns (inside a filter)||field|
EXCEPTION: <field> elements maintain the order they have in Jira, as that order represent the order of columns shown when the filter results are displayed in the issue navigator
|scrumKanbanBoards||scrumKanbanBoard||name, type, mainFilter|
|workingDays||workingDay||Natural order of weekdays, starting at Monday.|
|workingDays||nonWorkingDay||Increasing date order|
|column (inside Agile boards)||status||own value|
NOTE: All other children elements that are part of exported Agile boards (e,g, quick filters, columns, ...) maintain the order they had in Jira, as that represents the order that was configured by the board administrator.