Move ticket to another type via ScriptRunner automation

[César Vidal]

I'm trying to move a "Demand" ticket to another type (Incident, Enhancement or New App) based on a classification field. I just want to change ticket type in the same project, and I'm trying to do it through automation, in case the ticket is updated and classification field is populated, run a script that move the ticket. Is it possible? 

[Radek Dostál]

Everything is possible in the world of IT.

As to whether you should, I'd argue.. consider alternative ways.

Changing issue types may be simple, but it may also be a mapping hell. 

Changing issue types is usually a "I created this in the wrong place" or "We're reorganizing", it's not supposed to be a daily operation, and it's rather extremely rare to see it automated at that. (Can't say I'd have ever come across a script for it?)

The API for it may work sometimes, but it may fail the other times, sometimes moving issues is simple, but sometimes Jira would throw a bunch of mapping forms for you to fill out.

As you're asking in a rather unspecific way, I'm assuming you're not comfortable enough to deal with Jira API on your own all the way through and moving issues will be harder than you expect, especially to debug all possible scenarios and then maintain it going forward whenever some configuration somewhere changes and the script starts failing.

Probably, you might want to review the process because you shouldn't really need to change issue types based on a custom field value, it doesn't sound "correct" and you're only going to create something that will end up causing bugs and errors at some point. If you're moving issue types because of a custom field value, your process is the problem, not automating issue types.

[César Vidal]

Hello Radek,

I'm going to be more specific:

We have a demand management process in which the reporter doesn't know which type of ticket has to open, so we are considering to have a unique way to register demand through an specific issue type in JIRA Data Center (I think here I have the problem, because I can't move the ticket through ScriptRunner in JIRA Data Center). When the team analyzes it, they can now specify what type of work it is (evolution, incident, support... whatever) and they classify the ticket. Then, when the ticket is classified, the issue type should change because the workflow is different when the work is an incident or is an evolution. I have been testing it, and I can change the ticket through automation (via ScriptRunner) but it seems that the destination workflow remains inconsistent when changing the type.

I am considering other options due to the limitations of JIRA Data Center.

Maybe with this extra information you can help me.

Thanks in advance!

[Radek Dostál]

In that case, likely you're missing the step to migrate the issue to the new workflow. (I assume you simply change issue type of the issue in the existing script which would miss that.)

You could try this:

workflowManager.migrateIssueToWorkflow(mutableIssue, newWorkflow, mutableIssue.getStatus());

What this does in the background is set the workflowId and statusId:

public void migrateIssueToWorkflow(MutableIssue issue, JiraWorkflow newWorkflow, Status status) throws WorkflowException {
    GenericValue issueGV = issue.getGenericValue();
    this.migrateIssueToWorkflow(issueGV, newWorkflow, status != null ? ((StatusImpl)status).getGenericValue() : null);
    issue.setWorkflowId(issueGV.getLong("workflowId"));
    issue.setStatusId(issueGV.getString("status"));
}

However, the problem here is the issue's status is actually valid for the newWorkflow. In your case, if the issue's status doesn't exist in the workflow you're mapping to, you will also have to make sure to set the proper status rather than rely on the current one.

You can get the instance of JiraWorkflow using WorkflowManager, such as `#getWorkflow(Long projectId, String issueTypeId)` for the "new" issue type.

Then with that JiraWorkflow, you could check if the issue's current status is defined as a step, and if not, then use the default status for that workflow, and that should imo ensure that you are always setting the correct state.

Or, I suppose, a status to status mapping table.

Anyway you get the idea. The point is most probably your issues aren't being migrated to the new workflows which will brick them and you can't do any transitions because of it.