Selecting export options

After selecting which projects will be exported (either complete or only their configuration), you will be taken to this page:

Export filename

At the top, there is a text box where you can specify the name for the exported file. The system will generate a default filename, but you can change it to suit your needs.

The exported file will have a default filename like this config-dump_BDI1-ZH19-A0IA-E1XU_PB.xml where:

  • It starts with a fixed string: config-dump_ for configuration only exports and project-dump_ for complete exports.
  • BDI1-ZH19-A0IA-E1XU is the server id of the instance where the export was run
  • PB is the key of the exported projects. If all projects in the instance are exported, this will be replaced by ALL. If more than one project but not all of the existing ones are exported, this will be replaced by XX_PROJECTS where XX is the number of projects included in the export (for example 20_PROJECTS)
  • The extension will be xml for configuration only exports and zip for complete exports.

Export options

The "Filtering custom fields" options selects whether all custom fields will be exported or only those that are used by the exported project(s). Detailed explanations about the criteria for deciding whether a custom field is "used" by a project can be found here.

The "User export options" is a list that lets you select one way to handle user data during export. Available options are:

  • Full export: This the default mode. When a user name is found anywhere in the exported configuration, the plugin looks for the user and adds its description to the exported items. If the user is invalid, the export will halt with an error.
  • Ignore invalid users: When a user name is found which is not valid, the user and its description are not added to the exported items. The user name still appears as component or project lead, or in a permission/notification/issue security scheme in the exported file. Export will not halt in these cases. Currently, the plugin is able to detect an invalid user name in two situations:
    • When it cannot find a user for that name.
    • When the found user has an invalid email address (it does not conform to the pattern "X@Y" where X and Y are non empty strings)
  • Do not export: No user will be exported, regardless it is valid or not. Export will not halt on an invalid user name.

"Group export options" offers the same choices for export of groups. Take into account that currently the only case detected as an "invalid" group is when a group cannot be found for a given name.

What will happen when I load this configuration file?

When you are about to load a configuration file created with "Ignore invalid ..." or "Do not export" options, it is likely that it contains some references to users or groups (by their names) where those users/ groups are not included in the corresponding section of the configuration file. If a user/group with that name does not already exist in the target instance, there are some implications:

  • Except in very rare cases (e.g. users/groups are the default values in a custom field) the load will not fail.
  • However you are creating an inconsistency in your target instance. There will be a project, component, scheme,...using a user name or group name that does not correspond to a valid user/group.

"Filter export options" lets you control export of filters. The choices are:

  • None (default): no filter will be exported.
  • Shared with all users: exports filters shared with all users will be exported.
  • Shared with exported projects: exports filters shared with one or all the roles of any of the exported projects.
  • With all users or with exported projects: exports filters that are shared with all users or with any of the exported projects. This  is equivalent to the union of the filter sets exported by the previous two options.
  • All shared filters: exports filters that have been shared with somebody else. This means that private filters, that are only visible to their respective owners, will not be exported.
  • All filters (shared or private): export all filters in the instance, either shared or private.

"Dashboard export options" offers the same choices for export of dashboards. Take into account that if you choose to export some or all dashboards but none of the filters, those filters that are used from dashboards will be exported anyway, so that the exported configuration is complete.

"Scrum and Kanban boards to export" acts in a similar way. It lets you select which Agile boards will be included in the export. The available options are:

  • None (default): no Agile board will be exported.
  • Associated to exported projects: Agile boards that are linked to any of the exported projects will be included in the export. Boards associated to a project appear under the project name at the project navigation panel (see an example image here).
  • All Scrum and Kanban boards: all Agile boards existing in the instance will be exported, regardless of their relation to the exported projects.
Export of Agile boards requires that JIRA Agile plugin (in JIRA 6) or JIRA Software application (in JIRA 7) are enabled. Otherwise, no Agile board will be exported (even if you requested something else).

Finally, there are two buttons at the bottom that let you either launch the export or go back to the previous step in the export process. If you are exporting complete projects (i,e, their configuration, data and attachments) the export button will be called "Export complete project". If exporting only their configuration, the export button will be called "Export project configuration". As you can see, the same texts will be shown as page title and header.

Next step: viewing export results