moveIssue

Looking for the documentation on the newest versions of SIL Engine and the Simple Issue Language for Jira 8 for Server/Data Center? Click here !

Availability

This routine is available starting with SIL Engine 4.8.0.9 .

Syntax

moveIssue(JMoveIssueParams)

Description

This routine helps moving the issue (including sub-tasks, custom/standard fields, attachments) between projects. It gives the possibility to move between different projects and workflows by specifying the optional parameters passed in the JMoveIssueParams SIL Type.

Parameters

This is a structure which holds information about a filter.

Name	Field	Type	Description
JMoveIssueParams	issueToBeMoved	string	The issue to be moved represented by the issue key.
	targetProject	string	The project key of the target project where the issue will be moved.
	targetIssueTypeId	string	The issue type available in the target project represented by its id.
	targetIssueStatusId	string	The issue status available in the target workflow represented by its id.
	targetSubtaskIssueTypeId	string	The sub-task issue type (as there can be different issue types for sub-tasks) represented by its id.
	targetSubtaskStatusId	string	The sub-task status available in the target workflow.

Usage

The JMoveIssueParams Sil Type covers most of the use cases when moving an issue to another project. Some scenarios like different workflows, different issue types between the initial project of the issue that needs to be moved an the target project are treated by specifying the optional parameters.
Scenario 1: We have equivalent projects and workflows. If this is the case the only params that needs to be specified are the issue to be moved and the target project. This is available for the sub-tasks as well.
Scenario 2: We have different projects and workflows. In this case, we are forced to specify the issue type that is meaningful for our use case available in the target project as well as the new status as the current ones are no longer valid. Sub-task will need the same.
Scenario 3: Even if we have equivalence between projects and workflows we can still specify a new status(or/and issue type) when moving the issue to the target project. for example, you are moving the issue from TestProject to ProjectA and after moving the issue you want to change the status from "ToDo" which is the current one to "StartProgress".

Return type

string

After the issue has been moved the new issue key is returned.

Example 1:

//TestA and TestB are equivalent projects so the IssueType and Status remains the same during the migration because we know that they are still available in the ProjectB.
//If we want to change them and chose some other status or issue type, is our choice and we can do that by specifying the optional params. 
JMoveIssueParams params;
params.issueToBeMoved = "TESTA-192";
params.targetProject = "TESTB";
string newKey = moveIssue(params);
runnerLog("Issue has been moved. The new issue key is: " + newKey);

Example 2:

//In this example we are trying to move from a regular management project to a service desk project. They have different workflows and issue types in most of the cases so we need to specify the params.
JMoveIssueParams params;
params.issueToBeMoved = "TESTA-215";
params.targetProject = "JSD";
params.targetIssueTypeId = "10100"; // TESTA-215 current status is "InProgress" -- > 10100 = target status "WorkInProgress"
params.targetIssueStatusId = "10107"; 
//if we have subtasks, they need to be migrated as well
params.targetSubtaskIssueTypeId = "10000";
params.targetSubtaskStatusId = "10103";
string newKey = moveIssue(params);
runnerLog("Issue has been moved. The new issue key is: " + newKey);

When dealing with obvious mismatches between projects is recommended to specify the correct issue types, statuses available in the project that the issue is going to be moved. In case of something is not mapped correctly in the process, the routine will return an empty string ("")
and a relevant log message will be added.