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

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


1 badge earned


Participate in fun challenges

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


Gift kudos to your peers

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


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!


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
Community Members
Community Events
Community Groups

Change the Default Status When Moving between Issue Types

We've setup workflows for Reports and Issues that are different. We use reports to quickly add things we need to look into further, but that are not ready for a developer to begin work on. In order to prevent duplicated reports and issues in the same sprint, we Move issues from reports to bug (issue types). 

The move process tries to set the status to several steps further than it would if we were creating a new bug. Is the a way to set the default status when moving from one issue type to another? 

1 answer

0 votes
Derek Fields
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
Mar 27, 2023

@Chris Hubbs This isn't a direct answer to your question, but why are you moving the issue type? In general, a process that requires you to Move issues from one type to another is an indication of a faulty process. 

Having re-read your note a few times, I think that your first sentence should have be written:

We've setup workflows for Reports and Bugs that are different.

If that is correct, then what I understand is that a "Report" is some incident that may or may not require a developer to resolve. Until you have performed your root cause and know that the solution requires development, you don't want to schedule it into a Sprint. Once you do recognize it as a Bug, you move the Report to Bug and put it into the Sprint. If this is incorrect, then ignore the next paragraph and let me know where I misunderstood.

I would reconfigure your Bug process to allow all of the incidents to be Bug reports and get rid of the "Report" issue type. A Bug may not require any developer intervention. It may be resolved as "User Error" or "Feature, not Bug" or any number of other reasons that it didn't require scheduling into a Sprint. For those Bugs that are truly bugs and need developer resolution, they remain in the Backlog until the team pulls them into the appropriate Sprint. Then the team works them, just as they do today, until they are closed.

This has the advantage of a) treating all reports as potential bugs without having to worry about whether they are or not until you are ready; b) means you don't need a separate workflow; c) makes your metrics easier to follow.

Reports come in from a number of sources. Those get assigned to a sprint based on their importance. Analysts work reports and developers work bugs. A report goes to an analyst. If the analyst deems the issue to need developer work, it is moved from a report to a bug. Reports are how new features are spec'd.  The process works fine, other than one small issue, which is when moving the issue from report to bug, its defaulting to the wrong status. 

Suggest an answer

Log in or Sign up to answer
AUG Leaders

Atlassian Community Events