Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Manually edit the XML configuration file and replace the source instance IDs with the corresponding target instance IDs;

  • Import the configuration and then edit the workflow in the target instance to fix conditions, validators, and post-functions that are not pointing to the right custom field, group, role, etc.;

  • Developers can also create a custom PCJ extension that supports the affected workflow extensions; see Integration toolkit for developerssee our integration toolkit page.

Tip

If you need Project Configurator to handle workflow extensions defined by an app, raise an issue through our support portal.

...

  • Filters can be exported and imported, including the columns (fields) selected to show in the issue navigator if the filter has such a column layout selected and whom the filter is shared with (everybody, a group, all roles in a project, or a specific role in a project).

  • By default, filters that are shared with one or all the roles of any of the exported projects are exported. You can use the export option that enables the export of all filters or only some of them, based on how they are shared with other users. If filters are present in an XML configuration file, they will be imported with that configuration unless you select the export option to ignore them. See Export Options to learn more.

  • Filters without an owner are not supported. If a filter in the imported XML file has no owner defined, the app will treat it as belonging to the user who is launching the import.

  • If a filter is defined in the XML file as being shared with a project (either with all roles or a specific role), that project must either already exist in the target instance or be created as part of the import. The Create Additional Projectscreate additional projects import option allows you to automatically create these additional projects. The same applies to the project role if it is shared with members of a specific role in a project.

  • JQL permits the use of IDs instead of names to identify some objects, such as versions, components, priorities, resolutions, or custom fields. More precisely, the app supports:

    • The use of IDs to identify custom fields, either in the where clause or the ORDER BY part of the query.

    • All the uses of IDs in filter queries are described in Atlassian’s Advanced searching page, with the following exceptions:

      • IDs that identify users (Reporter, Assignee, etc.)

      • Use of IDs in the field Epic Link

      • Use of IDs in field Sprint

    • The app also supports the use of IDs in predicates about the issue history for all fields with the exceptions just described in queries like “Resolution changed from 3 to 5”.

  • When the app detects the use of an ID in the query of a filter it is exporting, it replaces the ID with the corresponding name in the exported query. This means that the original database is not changed by an export operation. If you want to remove IDs in filter queries in the original database, follow the procedure described in /wiki/spaces/PCKB/pages/84508879.

  • Filters are identified across instances by their name and the user name of their owner. See the following table for an example of situations when importing a filter:

    pcj-table.png

...

  • Dashboards are identified across instances by their name and the username of their owner, the same as filters. See the above table for a few examples.

  • By default, dashboards are not exported. You can use Project Configurator’s export options to enable the export of all dashboards or only some of them based on how they are shared with other users. If dashboards are present in an XML configuration file, they will be imported with that configuration unless you choose to ignore them using the import option.

  • If a gadget requires a specific app to be installed, you must have the same app and version installed in the target instance. If not, the import will load successfully, but if your user tries to open the dashboard, Jira will show an error for that gadget.

  • All gadgets listed in the Gadgets for Jira applications are supported. Any other gadget is supported (meaning it will be exported and imported successfully into another instance) as long as it meets either of these conditions:

    1. Its user preferences (configuration) do not refer to other objects by their IDs, and the referred objects exist in both instances.

    2. An extension for Project Configurator is available to handle that gadget type. More information on creating extensions for Project Configurator can be found in our Project Configurator integration toolkit page.

Missing references during export

...