moveIssue
- Jonathan Muse
- Shane Smith
- Anna Hryhoruk
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
Return Type
String
After the issue has been moved the new issue key is returned.
Example
//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);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".
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.
This routine can be used as a post function, however, occasionally this can run into some difficulty since it is still processing as part of the workflow operation while simultaneously the issue is getting moved to a different workflow. As a very simple minded person (me, the author of this sentence) once described the scenario “It’s hard to move a box while you are still sitting in it.” Switching the script to a listener can resolve those issues.