If we fix JRA-5159, would this fix your problem?

The reason I ask, is that quite often this is not the bahaviour that users are after. Closed/Resolved issues are sometimes moved, and people would like for them to stay in their status, rather than having to then manually put the issue through the entire workflow.

From what I can tell if JRA-5159 is implemented, you will be able to select any status during the move operation. So if you select the "first" status (in most cases "Open") then this will take care of this situation as well.

Therefore, may I resolve this issue as a duplicate of JRA-5159?

Thanks,
Anton

On further thought, perhaps JRA-5159 is not my desire. In my case, the
"Mover" of the issue should not be allow to select the state. The
entrance state, either by creation or move, has to be controlled by the
workflow.

I would be happy if the workflow allowed you specify options such as:
1) Issues moved into this project always get state XYZ.
2) Users can set the state of the issues
(please note, this would be needed at the workflow level, not the
project or workflow scheme level)

I could then, for New Features, select 1 = true, state is submitted, 2 =
false. If 1 = false and 2 = true, then the user could select the status.
This one is more difficult, as the status in one project's issue may not
be available in the other. Other options may be needed as well, such as
only allow the user to pick if the state doesn't exist in both
workflows. I believe this or something like this would satify both
needs.

(Another thought: If two projects are independently control, than a move
is really a create. Another solution/option would be to specify projects
that are "dependent", though this may be a little more confusing. )

A "Copy and Link" would also be useful here. Create a copy of the
issues, add it to the specified project as a new issue and then put a
link between it and the one copied.

Thanks,
Stephen

Can I ask, is the state the issues are suppose to move into the beginning state for every workflow? If so, would implementing JRA-1558 help?

Just FYI, it is possible to clone issues at the moment, which creates a new issue in the same project, but always in the beginning state. Then it is possible to move them. This is not exactly what you are looking for, but it might help.

If JRA-1558 is not what you are looking for, would you be able to describe the exact use case of the feature you are after?

The reason I ask, is that we would prefer to keep thing as as simple as possible. JIRA is quite complicated as it is, and adding extra switches such as selecting the status the issues are supposed to move into for every workflow, and being able to control (on per workflow basis) whether the user can select a status, makes things a lot of difficult to maintain. It also makes explaining how the Move operation works to new users more complicated.

As far as I am aware, no one asked for this functionality so its very unlikely that we would get a chance to implement this in the future. Therefore, I am trying to find a popular feature request that will suite your needs.

Cheers,
Anton

Just want to check and see if you have a response to my questions.

At the moment, I really feel like JRA-1558 is what you are mostly after, and therefore I would prefer to resolve this issue as a duplicate of JRA-1558, and ask you to vote for JRA-1558. This way we can clearly see which issues customers consider important. Having a lot of seperate improvement requests makes it much more difficult for us to choose what we should pay attention to next.

If you disagree, please let me know why JRA-1558 will not meet your needs.

Cheers,
Anton

When an issue is cloned, the new issue is always created in the "initial" status of its workflow.So if an issue is cloned in a project where the initial status in the workflow is Pending, the cloned issue will be created in the Pernding status. When JRA-1558 is implemented, it will be possible to select the project for a the new issue, however, the issue will still be created in the initial status of the workflow that is used for the selected project (and issue type).

This is the maiun reason why I believe JRA-1558 will cater for your needs. If not, please let me know what I am missing?

Cheers,
Anton

Cheers,
Anton

I think this still has problems with circumventing the workflow. I can
still move an issue from project X to project Y.
In the process of doing so, the current status is kept. This circumvents
all authority as defined by project Y.

I think this should be reopened, as control of issues through the
workflow is a huge necessity. The project's defined authority has to be
followed.
While the clone solution would work, the "Move" is in error and
available to the users.

Thanks,
Stephen

This circumvents all authority as defined by project Y. ?

Do you mean someone who couldn't have 'Resolved' an issue in project Y can move a 'Resolved' issue from project X to project Y, where he did have resolve permission?

Move issue operation is protected by the Move Issue Permission. So if the Move Issue functionality causes too many problems it is possible to disable it by removing the Move Issue permission from all users.

As far as I can see, "fixing" Move issue would actually involve implementing JRA-5159. Therefore if JRA-5159 and JRA-1558 are implemented, most of your needs would be addressed. Am I right in thinking so?

The reason I would like to have as few issues as possible to track needed functionality, is that having a lot of open issues decreases the chances that we will be able to address them. If there is an issue for a particular request I would really like to ensure that all the information and votes are captured on that issue, rather than being spread across numerous ones.

Please let me know what you think.

Cheers,
Anton

Yes. That is what I mean by circumvent the permissions. That's why I see
this as a critical bug.

Stephen