...
| title | Availability |
|---|
...
| Button handy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
| Table plus | ||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||||
|
Description
| Excerpt |
|---|
...
| ||
This function helps moving the issue (including sub-tasks, custom/standard fields, attachments) between projects. |
This function 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.
...
JMoveIssueParams
...
issueToBeMoved
...
string
...
targetProject
...
string
...
targetIssueTypeId
...
string
...
The issue type available in the target project represented by its id.
...
targetIssueStatusId
...
string
...
targetSubtaskIssueTypeId
...
string
...
| Info | ||
|---|---|---|
| ||
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. |
Return type
...
| Table plus | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| ||||||||||
|
Return Type
String
After the issue has been moved the new issue key is returned.
Example
...
| Code Block |
|---|
//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:
| Code Block |
|---|
//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); |
| Notenote |
|---|
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". |
| Info |
|---|
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 function will return an empty string ("") This function 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. |
See also
| Filter by label (Content by label) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|