Post Function to move an issue to another project

[Kunle kuteyi]

I need to move an issue to another project when its resolved. 

[Mahesh S]

Very much agreed to Nic's comment. However, if you still need to do this, you can write a scripted post function (from script runner) to move the issue. Or I would recommend to write a Custom listener for this case and move the ticket when the condition is met.

[Nic Brough -Adaptavist-]

I'm not sure you can squeeze all the required validation code into a script, they're limited in length.

[Mahesh S]

yeah but he can pretty much occupy within the space easily for this use case.

[Nic Brough -Adaptavist-]

Making the assumption that the configs are the same in the project might well be true now, but it might not remain so.

I ran into a system a few weeks ago where someone had done that, and the "move" script had nicely corrupted thousands of issues after an admin had innocently changed something for a user.

This is one of those things that we just cannot tell if it's ever going to bite.

[Mahesh S]

Oh that sounds bad! Thanks @Nic Brough -Adaptavist- 

@ola.. plz take nic's note seriously.

[Kunle kuteyi]

Thanks Mahesh. I will take note.

[Nic Brough -Adaptavist-]

You probably don't.  The desire to move an issue as part of a process flow indicates that either your process is wrong, or more likely, you've not set Jira up to match your process correctly.

Moving issues is an exception, it's mainly for "I created this in the wrong place" and "we are re-organising Jira".  It's a complex process that often needs a lot of information from the users, and not something you just drop into a workflow.

Why do you think you want to move these issues?

[Kunle kuteyi]

We had a process in place were external customers were raising issues in the wrong project.  To clean up we have to moved resolve issues to the right project.  

[Thomas Towkach]

Here's my 2 cents. As @Nic Brough -Adaptavist- suggests, fix the process not script. 

If you can't do either, may I suggest you Clone the issue copying the standard fields like Summary, Description, priority, or whatever fields (if you know the target project in advance) and then link the tickets together.

This keeps the original ticket in the 1st project as resolved, and give the cloned issue a link back to the original resolved ticket.

Scriptrunner you can add a listener to clone an issue and link which work brilliantly.

[Victor Alvarez]

I try to write a scripted post function (from script runner) to "move" the issue into the same project, for change the issue-type, workflow and status.

The scripted post function works fine, BUT there are transitions that have disappeared. Any suggestions?

 import com.atlassian.jira.issue.Issue
 import com.atlassian.jira.issue.IssueManager
 import com.atlassian.jira.component.ComponentAccessor
 import com.atlassian.jira.issue.issuetype.IssueType
 import com.atlassian.jira.issue.ModifiedValue
 import com.atlassian.jira.issue.util.DefaultIssueChangeHolder
 import com.atlassian.jira.issue.util.IssueChangeHolder
 import com.atlassian.jira.issue.CustomFieldManager;
 import com.atlassian.jira.issue.fields.CustomField

 import com.atlassian.jira.issue.MutableIssue;
 import com.atlassian.jira.event.type.EventDispatchOption;

 def constantsManager = ComponentAccessor.getConstantsManager()
 collection = constantsManager.getAllIssueTypeObjects()
 iterator = collection.iterator()
 while(iterator.hasNext()){
   issueType = iterator.next()
   if(issueType.name == "Destination-Type"){
     targetIssueType = issueType
   }
 }

 /*To change the issue type*/
 issue.setIssueTypeObject(targetIssueType)

 /*To change the issue status*/
 status_collection = constantsManager.getStatuses()
 
 iterator = status_collection.iterator()
 while(iterator.hasNext()){
   issueStatus = iterator.next()
 
   if(issueStatus.name == "Open Type 2"){
     targetissueStatus = issueStatus
   }
 }
 issue.setStatus(targetissueStatus)

 /*Commit*/
 MutableIssue issueToUpdate = (MutableIssue) issue;

 def currentUser = ComponentAccessor.getJiraAuthenticationContext().getLoggedInUser()
 issueManager.updateIssue(currentUser, issueToUpdate, EventDispatchOption.DO_NOT_DISPATCH, false)

[Nic Brough -Adaptavist-]

This is one of the reasons I tell people not to try it.

issue.setStatus is only for *new* issues.  You can't just stick a status on an existing issue, you have to transition it.  If you look through the Jira code for "move issue", you will find that when it detects that the target status is different to the current status, it goes through all the calls that "transition issue" makes.  There's about 40 lines of these, even after you ignore the post-functions and validators that you don't need during a move.

And never never try to do this as a post function, as it will corrupt your issue.  It needs to be a listener.

[Victor Alvarez]

Thank Nic for your suggestion.

I've improved and moved the script from post-function to listener, but always get an java.lang.NullPointerException ERROR.

What could be failing?

 import com.atlassian.jira.issue.Issue
 import com.atlassian.jira.issue.IssueManager
 import com.atlassian.jira.component.ComponentAccessor
 import com.atlassian.jira.issue.issuetype.IssueType
 import com.atlassian.jira.issue.ModifiedValue
 import com.atlassian.jira.issue.util.DefaultIssueChangeHolder
 import com.atlassian.jira.issue.util.IssueChangeHolder
 import com.atlassian.jira.issue.CustomFieldManager;
 import com.atlassian.jira.issue.fields.CustomField
 import com.atlassian.jira.issue.MutableIssue;
 import com.atlassian.jira.event.type.EventDispatchOption;
 import com.atlassian.jira.ComponentManager
 import com.atlassian.jira.workflow.WorkflowManager
 import com.atlassian.jira.workflow.JiraWorkflow
 import com.atlassian.jira.config.ConstantsManager
 import com.atlassian.jira.issue.status.Status

 Issue issue = (Issue) event.issue;
 
 IssueType newIssueType = ComponentAccessor.issueTypeSchemeManager.getIssueTypesForProject(issue.projectObject).find{it.name=="My Issue Type 2"}
 if (newIssueType) 
   issue.setIssueTypeObject(newIssueType)
 
 // get the mutable issue
 IssueManager issueManager = ComponentAccessor.getIssueManager();
 MutableIssue issueToUpdate = issueManager.getIssueObject(issue.key)

 // get the desired workflow: 
 WorkflowManager workflowManager = ComponentAccessor.workflowManager
 JiraWorkflow newWorkflow = workflowManager.getWorkflow("Workfflow 2")

 // get the desired status
 ConstantsManager constantsManager = (ConstantsManager)ComponentManager.getComponentInstanceOfType(ConstantsManager.class);
 Status newStatus = constantsManager.getStatusByName("Status 2")

 // change the transition
 workflowManager.migrateIssueToWorkflow(issueToUpdate,newWorkflow,newStatus)

[Nic Brough -Adaptavist-]

Almost everything could be failing, it's impossible to tell without the full error, but at a guess by just looking at your code, I'd say the iterator is not finding the new issue type, or if it is, it's not valid for the project you're in.

[Victor Alvarez]

The iterator find the new issue type correctly, and is valid for the project. I checked it.

This is the start of the error log. Any idea? Maybe some Tempo plugin needed:

2018-07-06 12:35:23,228 ajp-nio-8009-exec-1 ERROR [o.a.c.c.C.[.[localhost].[/].[action]] El Servlet.service() para el servlet [action] en el contexto con ruta [] lanzó la excepción [java.lang.NullPointerException] con causa raíz
java.lang.NullPointerException
at com.tempoplugin.service.workflow.TempoWorkflowServiceImpl.isLogWorkDeniedInWorkflow(TempoWorkflowServiceImpl.java:102)
at com.tempoplugin.worklog.validation.TempoIssueValidationResult.isJiraPermissionWorkDeniedPropertySet(TempoIssueValidationResult.java:147)
at com.tempoplugin.worklog.validation.TempoIssueValidationResult.calculate(TempoIssueValidationResult.java:119)
at com.tempoplugin.worklog.validation.TempoIssueValidationResult.access$100(TempoIssueValidationResult.java:25)
at com.tempoplugin.worklog.validation.TempoIssueValidationResult$Builder.build(TempoIssueValidationResult.java:199)
at com.tempoplugin.issue.TempoIssuePanel.doDefault(TempoIssuePanel.java:118)
...

[Nic Brough -Adaptavist-]

The config of Tempo in the target project is incompatible with the data on the issue you are moving.

This is why scripting "move" is a bad answer to a broken process - you either need to be 100% certain that the source and target projects have identical configuration in all aspects, or you need to validate and amend as its needed.

Even if you get this script to work, an admin (even a project admin) could easily reconfigure one of the projects and break it, unless you do ALL the validation.

Please, step back and have another look at why you are moving the issues, and why you are trying to script it. 

[Perry Tancredi]

Here is Atlassian's suggestion of cloning and deleting using an Automation: https://support.atlassian.com/cloud-automation/docs/move-an-issue-to-another-project-using-automation/