KIWI™ features

KIWI™ is the tool that enables users to export or import your workflows in just a few seconds. Designed to satisfy many customers requests, this app offers you the following features:

Exports/imports a workflow

KIWI™ exports and restores the selected workflow, carrying over all the steps, statuses and transitions:

The workflow statuses are carried over during export and created or updated on the Jira import instance during import. The mapping of statuses is done by name on the destination server.
If on the Jira import instance there is a status having the same name as exported status, the existing status will be updated to match the exported one, otherwise the status will be created.
The transitions used in the workflow are exported and imported including conditions, validators and post functions.

Carries SIL scripts with the workflow

If you are using our Power Scripts™ for Jira app and you have created SIL™ scripts (validators, conditions or post functions) on the transitions of the exported workflow, these SIL™ scripts will be exported and restored on the Jira import server.

While importing if on the destination server there is a SIL™ script file having the same name and path with a SIL™ script from the kiwi file that is being imported, the existing SIL™ file will be overwritten. You will receive a warning message in the Import page at Step 2: Actions for the action Create or update the SIL™ files (the action can be found and also disabled in the section General actions).

Exports/imports Issue type screen schemes

KIWI™ exports/imports the Issue type screen schemes related to the selected workflow.

What does related mean?

An issue type screen scheme will be exported if it is used as a screen scheme at least in a project that associates with the current workflow.

The reason to export was to recreate the Create/Edit/View screens that can be associated with the current workflow project on the destination server.

There are following associations in Jira's documentation:

Project -> Issue Type Screen Scheme -> [Issue Type, Screen Scheme].

And each Screen Scheme contains the necessary screens: Create/View/Edit.

[Issue Type, Screen Scheme] represents a mapping between the issue type and the screen scheme.

For instance the issue type "Bug" can have an associated screen scheme, therefore it has specific Create/View/Edit screens that can be different to issue type "Task" and specific screen scheme.

An Issue Type Screen Scheme (ITSS) contains one or more associations between an issue type and a screen scheme, so our app exports those screen schemes that are present in the exported ITSS.

Screen schemes that associate the issue operations to the screens. These screens are also exported/imported by KIWI™, along with the screens used in the workflow for transitions.

Issue type screen schemes and Screen schemes are mapped by name. If there is an issue type screen scheme with the same name on the Jira import instance, it will be updated to match the exported one. So it will have the same description and [issue type, screen scheme] associations. Otherwise the issue type screen scheme will be created.

Exports/imports workflow related screens

KIWI™ exports and imports all the screens used directly in the selected workflow (screens that are configured as Transition View in the workflow transitions), and also all the screens from the Issue type screen schemes the workflow is related to.

The screens are mapped by name during the import. Every exported screen is analyzed, and if the screen exists on the Jira import instance, found by name, it is updated to match the screen from the exported file. It means to replace all the entities, for instance tabs and custom fields of the updated screen with the entities of the exported screen (we do not merge the two screens), otherwise the screen is created.

Exports/imports workflow related issue types

KIWI™ exports all the issue types from the contexts of related custom fields and that are found in the related issue type screen schemes.

Choose issue types to be imported in the import page. Only custom fields that have at least one of the selected issue types associated in their context or that have global context, and only the relevant issue type screen schemes associations for the selected issue types are imported.

Issue Types are mapped by name. Every exported issue type that is selected for import is analyzed, and if it exists on the Jira import instance, found by name it is updated to match the issue type from the exported file otherwise the issue type is created.

Exports/imports workflow related custom fields

KIWI™ exports/imports all the custom fields from the screens related to the workflow (for instance transition screens and the screens that are found in the related issue type screen schemes).

KIWI™ also exports the custom fields that are not associated directly with the workflow. KIWI™ also carries over all the custom fields that are specific to the Create/Edit/View screens only in the ITSS and not in the workflow.

These custom fields are exported along with their contexts - Issue Types and Projects.

The projects used in the contexts must exist on the destination server. The search is done by project key. Otherwise, a project mapping may be configured at Import Step 1: Import Options section. Otherwise the contexts are partially created/updated using the existing projects, if at least one project for the context is found.

During the import every custom field (let's name it exported cf) that is available in one of the exported screens is mapped by using the following algorithm:

KIWI™ looks for a mapping/match using the Change action link from the Import page Step 2 or from the mapping file.
If there is a mapping/match defined in the mapping file, it gets the custom field from the Jira Import instance. The existing custom field is updated to match the exported custom field.
Otherwise if custom field that has the same name and the same type is found, the existing custom field is updated to match the exported custom field.
Otherwise the custom field is created.

When a custom field is updated, the name, description, the context(s) and the searcher are updated. KIWI™ also offers you the possibility to change the custom field actions directly from the Import page.

To be short, choose to update a custom field by selecting the update action and the desired destination for the proper custom field, or decide to create a new custom field.

Updating or creating a custom field involves carrying over its name, description, searcher and contexts. For each context the context name, description, issue types, projects, default value, and options -if any, for example for the Select List/Radio Buttons are so on. Also, for the cPrime provided custom fields, the special configurations are exported/imported by KIWI™.

Generates .cfmap files

A successful import generates two mapping files: the current and the next mapping file in the JIRA_HOME_FOLDER/kepler/kiwi folder.

The next mapping file is named using the following pattern: <imported_workflow_name>_next_<timestamp>.cfmap. It contains all the mappings resulted from the import according to your used .cfmap file and according to your screen selection, including the created custom fields. For an update custom field action, a new entry with the match/mapping [the source custom field -> the destination custom field] is added to the file. For to create custom field action, the entry contains the source custom field ID mapped on the newly created custom field ID.

The current mapping file is named using the following pattern: <imported_workflow_name>_current_<timestamp>.cfmap. It contains all the mappings according to your used .cfmap file and according to your screen selection for the custom fields existing on the Import server. For an update custom field action, a new entry with the match/mapping [the source custom field -> the destination custom field] is added to the file. Nothing is added to this file for to create custom field action.

For both mapping files names <timestamp> represents the date when the file is generated, in the yyyyMMddHHmm format.

For extra functionality of custom field mapping file take a look at Custom Fields Mapping.

Generates a SIL™ aliases file (for Power Scripts™ for Jira users)

If you are using our Power Scripts™ for Jira app (the SIL™ provider) you may have noticed that there is a sil.aliases file in the Kepler folder of your Jira Home folder. This file maps the custom fields to more easy readable names that can be used in the SIL™ scripts. The export embodies the entire file form the source server, including the comment lines.

A successful import generates this file in the Kiwi home folder with the name: <imported_workflow_name>_sil_<timestamp>.aliases, where <timestamp> represents the date when the file is generated in the yyyyMMddHHmm format. For instance, the file Workflowfortest_sil_201310071330.aliases is the sil.aliases file generated when importing the workflow Workflowfortest on 07.10.2013 13:30. This file contains only those custom field aliases that were imported, re-mapped according to your .cfmap file and according to your screen selection.

Offers tools to merge CF mapping files and sil.aliases files

Kiwi™ offers the tools to merge the generated .cfmap and sil.aliases files. You can keep the sil.aliases file up to date or create mappings that can be reused.

Executes SIL scripts at the beginning and in the end of the workflow

Add to your exported workflow a list of pre-import and post-import sil files that are executed on the Import Jira instance from the Export Workflow page, before(the pre-import files) or after(the post-import files) the main import is executed.

Important notices

To restore the contexts for custom fields, the projects (the search is done by project key) should exist on the Jira import instance before import or a mapping must be defined for a missing project in the Import Options section. Otherwise, the contexts are partially created/updated using the existing projects, if at least one project for the context is found.
KIWI™ does not export/import things related to a project, like Workflow Schemes, Field Configuration Schemes, Field Configurations and Issue Type Schemes. If needed, these must be manually created and associated to projects. The Issue type screen schemes are carried over by KIWI™, but the association to the projects must be done manually after the import.