Have you ever been bothered by the fact that there’s no easy way to move issues between Jira instances? You create a new issue on one Jira server only to realise that it should have been created on another Jira server. This is probably something that users of Atlassian support encounter occaisionally when they register issues on jira.atlassian.com instead of support.atlassian.com and vice versa. As my ShipIt Day V project I decided to right this wrong (cue heroic music).

The plan

250px-Knightlogo.jpg
As with most ShipIt Day projects I started with grand ideas. It was “gonna have AI and stuff just like KITT from Knight Rider and make your coffee and stuff while you waited”… well not quite. I was hoping that I could transfer an issue, its attatchments and history between instances of Jira. I was planning on trying to work out a way of dealing with the differences in configuration between Jira instances by getting Jira to try its best to find a mapping between the issue fields. The results would be shown in a split screen showing the current issue on the local Jira instance and the create issue screen on the remote Jira instance with as many of the fields filled in as possible. When the user had edited the create issue form on the remote server, the local instance of Jira would put that issue into “Migrated” state, and all the comments and attachments for the issue would be transferred from the local to the remote Jira instance. Unfortunately I didn’t quite get the project to this state.

The execution

It was clear, pretty early on that the initial plan was perhaps somewhat ambitious and that I’d have to be happy with the something more akin to a jalopy, at least it would get me there. CEO, Scott, and fellow Jira developer, Chris, referred me to some documentation about different ways to create issues that was very helpful. In the end I decided to use the HTTP request issue creation interface. This allowed me to pre-populate the Create Issue form with the details from the current issue using HTTP GET parameters. I also used used YUI for the Java Script and Chrome.

The final product

car.png
The final product at these ShipIt days is often somewhat underwhelming given the grand plans that I dreamt the day before. Much as this drawing needs its label, “Car”, so that it can be identified as being a descendant of the original idea (i.e. KITT).
Issue_operation.jpg I added a new operation to the list of issue operations which copies the current issue’s basic details to the remote instance.
Issue_chooseInstance.jpg When the user clicks on the operation it opens a pop-up where the user can choose which instance of Jira the issue should be copied to and the project, configured on that Jira instance, that the issue should be copied under.
createIssue_remoteInstance.jpg The user is then forwarded to the remote Jira instance they chose with the create issue form already (mostly) filled out.

Still to do

There are still a number of things that it would be nice to do, apart from a general clean-up of the code, before this change was shippable:

  • The external Jira instances were hard-coded. This should be managed via some pages under the administration tab.
  • Attachments and comments should be copied across to the remote instance once the Issue has been successfully created.
  • Custom fields should be automatically filled out (despite differences in custom field Id etc).
  • It would be nice to have split screen editing of the remote issue and the local issue so that, for instance, custom fields that the user could fill out custom fields on the remote Jira instance that weren’t able to be automatically filled out.
  • The status of the issue on the local Jira instance should set to a new status (e.g. Moved to Remote). Similarly there should be a comment on the issue created on the remote instance that it has been moved.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now