Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,465,081
Community Members
 
Community Events
176
Community Groups

Moving Issue does not allow to change Status during moving

Edited

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":

image.png

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

 

1 answer

0 votes
Mark Segall Community Leader Dec 07, 2022

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.

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 Community Leader Dec 08, 2022

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.

Like Gerrit Berberich likes this

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
SERVER
TAGS

Atlassian Community Events