What are the drawbacks of changing issue types during a workflow?

[Dale Wolfe]

Given issue types A, B, and C all using the same workflow, what are the drawbacks of transitioning the issue type from A to B to C during various states?

I have read and understand that automatic transitions can be tricky (https://community.atlassian.com/t5/JIRA-questions/Changing-issue-type-when-a-workflow-transition-occurs/qaq-p/127801) but are there any other technical reasons?

I realize that a custom field with one issue type could be used however, the config of an issue type controlling the screen schemes is very important to the overall presentation/editing during various states of the workflow.  Also, multiple workflows are not an option.

Cheers!

[Rachel Wright]

Hi Dale,

Can you tell us more about what you're trying to accomplish so the community can propose some implementation options?  In the mean time...

Don't Make My Mistake

I'll tell you that moving issues between types in a project, as part of the standard process, was the worst mistake I ever made in JIRA!  My scenario was this:

Get the requestor to submit a business case, using an issue type called "Business Case" with fields and a workflow related to reviewing and approving the business case.  Then, use the "Move" command to change the issue to a different type, where development information was collected and the development process started.  I thought this was BRILLIANT when I built it, but regretted it every second after.  

Count how many clicks the move process takes and you'll see I added a lot of manual work for myself.  I also added a lot of unnecessary change records in the database for no good reason.

I was trying to segment two different processes.  Instead, I should have built a better workflow and encouraged users to filter by status, not issue type.

3 years later I've killed that mess and a "Move" action is no longer part of the expected process.  Oh, and this configuration mess took me 10 hours to undo on one super fun weekend.

Hopefully I haven't derailed too far from your original question.  But even if I did, someone might read this one day and not make my mistake.  So yay!

Cheers,

Rachel Wright

[Nic Brough -Adaptavist-]

I can't help but agree with Rachel here.

  "Move" has three basic use-cases:

• A mistake where someone put it in the wrong project
• The issue type needs to change
• Merging projects

If you are trying to use "move" as part of a standard process, then my instincts are screaming "broken process"

[Dale Wolfe]

Actually, my scenario might be close to what Rachel is describing but I'm not at all considering a "Move".  

The issue type is simply changed via editing the issue at various points along the workflow.

[Nic Brough -Adaptavist-]

Theres a couple of conceptual problems with this

First, in the real world, an issue type is usually not something you would generally change.  To change it regularly implies you're using it to represent the wrong thing.  When it's a bug, it's always a bug, it's not going to morph into a story or an epic, unless it was raised with the wrong issue type to begin with.

Second, on the more practical level, the issue type in JIRA is a fundamental structural thing, not a trivial indicator.  A lot of configuration hangs off the issue type. Changing the issue type (often) changes the entire behaviour of an issue, with different fields and processes kicking in.  It's not a trivial thing to change an issue type.  Unless the configuration for two issue types is the same, you must go through a move process so that all the changes to the structure can be validated and explained to the user.

[Dale Wolfe]

I appreciate the insight.  I do understand the structure of the issue type.  It's this structure specifically to control screens (with tabs) that allows for input of specific, localized data to be performed along one workflow.  The other configuration aka workflow etc. of the issue types is indeed kept identical except to trigger screens.  If there's another method or Atlassian has plans to offer screen schemes controlled by a custom field - please advise!