[Help / Advice] Moving Issues is Such a Pain

Question

Hey Everyone, I'm pretty new to the world of JIRA and banging my head against the wall trying to figure out a way to triage our issues that fits well into our workflow. Our company has a general "untriaged" project where we let everyone file issues and then we go through and triage those issues into our active projects. I've ran into several productivity problems doing this and was wondering if JIRA experts out there might have some advice or tricks to help make this easier. Here's a quick list of nags at the moment.

1) Moving an issue changes the project I'm working in.

We go through a list of bugs to triage but as we move them I have to open the "move issue" process in a new tab each time or I lose the place in our triage Queue, Is there anyway to move an issue without it losing my place in the list of issues I am currently going through?

2) Issue bounce back

When selecting a new project type, it doesn't maintain the selection "Current Issue Type" even though we use the same workflow for all projects. Is this a bug or is there anything I can do to fix this?

3) Change data during the move process

I would really like to be able to change *any* of the data about the bug as part of the move, process. Is there a way to change the "update fields" page to have all the information about the bug, the same as editing it?

4) The confirmation page

Is there any way to disable this page? I don't really need it and it's just an extra click.

Generally it feels like the workflow for moving an issue is super complicated, requiring a total of at least five clicks to make it through the process where I would love one or two. Any advice or JIRA config stuff I could change to simplify this would be greatly appreciated.

Stephane Oberlechner · Answer

Hi KOPM I Can read at the end : "Any advice or JIRA config stuff I could change to simplify this would be greatly appreciated." If you want to limit these pb, please keep your Jira simple.I know It's not easy when users ask you to build each day projects, workflow, customfiled .... Please, tell them (it's my summary of the last summit) : * Project is the box to collect issues. 3 box for 1 team Max, and not 3 box per user! * Workflows are the languages to communicate : How many languages do they speak ? -> you have the response * Customfields are the vocabulary : do you want an heavy dictionnary or not? S.U.P : Simplification <-> Understanding <-> Performance

Nic Brough -Adaptavist- · Answer

Hmm.

* That is correct behaviour - Jira keeps track of the "current project you are active in"
* That is a bit of a pain, yes, but it's a minor niggle.  I couldn't find an enhancement request for it though (In Atlassian's Jira for requesting fixes/improvements etc)
* There's a massive can of worms on both cloning and moving in Jira.  The problem is that the current functionality of "just go do this" is a) simple in terms of coding and b) pretty much what most people actually need.  There's constant talk from people who want to change this behaviour, but I've yet to see anything resembling a consensus.  You've said "I want to change any of the data", which is fine, but a lot of other users only want to change the summary.  Or the description.  Or the version and component.... or... or...
* The confirmation is a good extra check for many people, but it would be nice to be able to turn it off for your case.  I think you're heading towards coding in order to do it though.

The other answer is probably not what you want to hear, but it's "dump the triage project".  Jira is not designed for a huge amount of moving, it's built on the assumption that users usually know which project to put things in to begin with, and moving is not day to day activity.  Write guides for poeple to get the project right.  Put direct links into docs so that users land in the right project (and create screen) by clicking on them.  Add a step at the beginning of the workflows, so that "open" means "no one has looked at this yet" and your triage people then move things if they're wrong.