We really need this as well. 

We clone an item and then move to a new project to generate a new request item and need them to force into the first status of that workflow. 

Any update on a possible schedule for this request for improvement ?

It is really causing issue to prevent to select the target status unless the source one is not existing in the target project.

In many cases, the most apporiate status when moving the ticket is "NEW" or the starting status of the workflow, clearly.

Restriction and conditions controlled through the workflow transitions can't be applied, when moving to a status that is quite late in the process.

Thanks for your help.

Regards.

Since the issue was created 12 years ago and is still not scheduled, I'm not hopeful that it will be implemented soon.

Are there any known add-ons that would accomplish the functionality that this issue is requesting?

We have to acquire several approvals before a requested change can be made. For example, the status "IT Manager Review" may appear as Step 1 in Project A, but as Step 2 in Project B. For Project B, Step 1 is "Data Owner Review". If an issue is moved from Project A to Project B while the issue is in Step 1, then "Data Owner Review" never occurs. It's not a matter of simply reordering the steps if "Data Owner Review" isn't a necessary step in Project A. This is a serious issue for us. It would be nice if there were an option to set the status as a default when moving an issue.

This issue is extremely problematic for us. Our use case:

• Issue is created
• Issue is worked on and then resolved. During resolve transition, Resolution field is filled out.
• Issue is then moved to another project, or to another issue type in the same project
• Issue is still resolved because Resolution field was never cleared out, even if it was moved to the "Open" status (where any issues that were created with this project/issue type in the first place would never be able to have a resolution filled out - since it's in the initial status).

We have the same issue as many have mentioned. We have 2 projects and occasionally move an issue between. But the workflow status names in each project are different. So the wizard asks users to choose the new status, but we want to limit this choice, not allow every status to be chosen. Now a user might skip some required fields / steps by choosing a status that is much later in a workflow.

This is very important feature since when issue/s moved to another project its/their state is changed. I was surprized when I found that it is not possible.

We need this also urgently. We are in exactly the same situation as described by Joey Potter

We have different workflows for Bugs and Change Request for instance. At some point both have a state Open, but with a different meaning and for the CR the Open state comes further in its life cycle than for the Bug. So when our users have to move a Bug to a CR (not quite uncommon), they always go crazy a little bit. And there is no workaround, because at this point we do not allow the steps back process-wise.

I really hope this feature will be scheduled in the near future.

Hi Jed,

Thanks very much for your time and answer. Yes, I figured that is what it was doing (i.e. looking for the same Status ID).

Although I myself have never seen it any other way, one of our user groups is certain that it was different in some prior version of Jira (i.e it 'used to allow them to change status even if it was the same), but then it stopped during one of the Jira upgrades. It might have been before I got to Polycom, so I cannot be certain. Or.. they could be mistaken .. Or, it's possible that we had two status values with the same name (or misspelled but still look-alike name). In which case, when they were moving an issue, the underlying status IDs were different, and therefore it used to ask them to map. Any of those thigns are possible, so if you say that it was always like this in Jira, I certainly believe you.

In any case, it would be nice (in the future) to implement what we are requesting.. The ability for a permission group to override the status mapping during an issue move – even if the Status ID is identical among the projects (or issue types for that matter). Thanks for your consideration.

Joanna