The move issue operation should respect workflow restrictions and permissions in target project or issue type.

There are two issues reported related to this, JRA-16595 & JRA-39112, but I thought I'd put a general suggestion that encompasses the whole problem.

Problem

As long as the user has create issue permission in a project, they can move an issue to it and more importantly, to ANY workflow state in the target workflow. This creates an issue in a use case such as:

-If you are using in a project (or specific issue type) a workflow that has specific restrictions as it is being used in a strict approval process. The ability to use the move issue operation to "bypass" any workflow conditions and validators renders the approval workflow useless. (not saying that someone would necessarily maliciously seek to do so)

-Similarly, it could be moving to a different issue type within the same project that is using a different workflow as well.

Looking at the consequences mentioned in the other linked issues, simply put, the "move issue" operation is one could say "too powerful" as it doesn't respect workflow conditions and permissions in the target project.

Solution

Removing create issue permissions to a project or move issue permissions is in a lot of cases not really an option and therefore not a solution.

What would be a solution apart from all conditions and permissions being taken account by the code, would be the ability to disable moving TO a project/issue type either via permission or otherwise so that at least any really problematic cases can be avoided.

Workarounds?

At least for my case I am looking at whether it is impossible to employ a hack to remove certain projects or issue types from the ui dialogue similar to https://confluence.atlassian.com/pages/viewpage.action?pageId=301663662.