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

Problem

As long as the user has Move Issue and Create Issue permissions 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.

It would be good to apply the logic in the workflow's condition to filter out the new workflow statuses, for example:

In addition, we should consider adding a third input to select a transition to the new status, so the validators, POST functions, and transition screens can be applied during the move, so we don't end up with an empty Resolution field when moving an issue to 'Resolved' - see JRASERVER-16595