nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Post Function to move an issue to another project

Kunle kuteyi_9rsngg

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

Accepted answers

All comments

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?

Mahesh S_y9hwt0

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_y9hwt0

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.

Kunle kuteyi_9rsngg

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.

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.

Thomas Towkach_i3m1p0

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.

Perry Tancredi_q81b1l

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/