Moving Issue does not allow to change Status during moving

[Gerrit Berberich]

Hello,

we have a project & board for local Key-User requirements and after validation they should be shifted to another (IT) board. When moving the status is taken from the origin board which does not fit to our expactation (to choose the status or even start at the beginning) of the workflow.

Unforunately when moving issue it shows that there is a possibility to "Select New Status" but this step is never provided when clicking on "next":

We have found these tickets/ideas:

https://jira.atlassian.com/browse/JRASERVER-33059 (closed because too less attention)

https://jira.atlassian.com/browse/JRASERVER-74234

Hopefully this will be considered soon. Are there other ideas from the community?

Thanks,

Gerrit

[Mark Segall]

Hi @Gerrit Berberich - Jira is simply not designed for moving issues as part of a regular process.  It should be considered more for exception scenarios.  And by design, mapping of statuses is only required when the source/target workflows don't share the same statuses.  Thus, it will skip the status mapping step if the status exists in both.

You have two options:

1. Consolidate work into the same project - If there is a significant amount of hand-off, it may be a scenario where it just makes sense to share the same project with different project boards.
2. Create a new linked issue on the target project - If the two teams have integrated work, but plenty of other activity to warrant maintaining their own respective projects, then this would be the route.  In this use case, team 1 would work an issue from Open to Resolved with their own definition of Done.  Upon completing their work, team 2 would get a new linked issue and work it from open to done against their own definition of done.

If you decide option 2 is the best, you could leverage Jira Automation to help facilitate creation of new linked issues for the other team.

Hope this makes sense.

[Gerrit Berberich]

Thanks @Mark Segall  for your detailed answer. Yes Option 2 would better fit to our process and expectations.

Nevertheless we want to "copy" all comments/whole communication flow and also want to give transparency in a single ticket for initial reporter (local Key-User) and us (IT doing finally the realization). So linking an issue might be too hidden.

Also we need a separate project as the local Key-User will process the workflow there with global Key-User before handing over to IT.

[Mark Segall]

You may want to look into marketplace apps like Deep Clone for this.  They will copy over the comments.  You could potentially use that and then in the vein of transparency, update your processing to inform the reporter that you're now handing off the issue to another team and then the newly created IT issue becomes the source of truth for communication until they're complete.

I know it's a bit clunky, but with the Move function currently designed as a closed off process (adding this functionality would not be trivial), there are not a lot of options.