Sadly this is far more complex than one would assume. In Cloud no 'move' REST API exists, so this wont happen until JIRA adds such an API in Cloud.
In server this could fail very often due to different workflows, field configs, screen schemes etc. The manual move operation via the UI requires a several step wizard. Automating this isn't ideal since it will most likely fail more often than it will pass.
Warning: The workaround results in certain fields being lost i.e. history, comments, attachments, and linked issues
For a workaround, see https://docs.codebarrel.io/automation/kb/move-issue.html
I understand that you currently do not support the moving of a Jira issue and that you have a recommendation in place for cloning and deleing an issue, AUT-90.
This becomes problematic when we are keeping the issue in sync with an external application like Remedy or Service now. The external system references the original Jira issue number and cloning and deleting the issue breaks the synchronization.
We have an interface that creates Jira issues in a main (a.k.a. mother ship) JIRA project. We want to use Automation for Jira to then move those issues to a new JIRA project(s) based on Automation Rules. We need to keep the issue key as it is tied to the external system and provides bi-directional updates. This is through Tasktop and BAO interfaces.
I understand this is challenging but we would be moving based on defined criteria. I know you have the above referenced ticket, but I wanted to see if this was something on your radar to address. It is becoming critical for our teams and we are getting pressure to move to a different plugin to get this support (JJUPIN/Powerscripts).
Any feedback would be appreciated.
Jodi Gornick | CGI
Director | ProAction-AS
The linked issue - has been resolved