https://getsupport.atlassian.com/browse/PCS-263435

this is a SERIOUS issue - there shouldn't be a way for users to bypass approval steps by moving an issue

This issue allows users to bypass the entire approval workflow. They create the issue in a project where they have the rights required to put an issue "in progress", and then move it to a project where they do not have the rights to approve issues.

Nicely hacked past the enforced workflow.

Because of this, as a product manager, I get confronted with pull request for features I did not know somebody was working on and where I don't even agree to the initial issue.

This leads to frustrations for all parties involved.

It would have been much better if this was stopped before it was even started.

This is a big issue as it provides a loophole for any sort of approval workflow when migrating issue types. Please implement a feature to limit the status options during migration.

At the moment, a user who is migrating a ticket from a different project can arbitrarily choose to put their ticket into whatever status they like. Our workflow (in the destination project) typically involves creating a submission review state before a ticket is accepted for work. It would be ideal if tickets migrated into our project could, by default, have their status reset to the creation status. This could be a checkbox.

Could we please expedite this bug.
I am not sure how this is considered as a feature request. This is a very common scenario to move issues from one project to another or one request type to another but once the issue is moved then it should follow all the steps of the new WF including the approval step. 

Let me know if we need to get into a call to get this ticket the right attention.

Thanks in advance for your anticipations!

This is a much-needed improvement required in Jira Service Management. Below is what we are facing on a day to day basis.

 
Project A with "Report An incident" Request Type and the workflow has these statuses- Open, In Progress, Waiting for Customer, Customer Responded, Pending, Resolved, Closed.
 
Project B with "Enablement Request" Request Type and the workflow has these statuses- Waiting for Approval, In Progress, Declined, Customer Responded, Waiting for Customer, Resolved, Closed.
 
Note that the "Enablement Request" ticket in Project B has to go through an approval process before it gets to the "In Progress" state.
 
Now, if I move an "In Progress" ticket of the "Report an incident" type from Project A to the "Enablement Request" type in Project B, as per your explanation, it will automatically skip the "Map Status" section in the Move screen. In this case, the ticket will be landed in Project B with In progress status. 
 
As I said any "Enablement Request" has to go through an approval process, but in this scenario, the approval process got skipped. And it creates a whole lot of confusion and process issues.

Well, ain't this a remarkable example of poor product management
Can't schedule a feature for 14 years? GJ Atlassian  

Repeating Dale Peters' question above, given this issue is open for 14 years, does anyone know an alternative solution to the problem? I.e. Is there a way (through an add-on etc.) to force all moved issues to end up in a particular status (e.g. Status: INBOX)?

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

Jag,

The status ID is what is matched when migrating issues between projects. The wizard simply looks to see whether the originating status matches a valid status in the target workflow, if not the status must be selected. There is no override for this behavior at the moment.

Joanna, that seems to be a reasonable way in which to implement it.

Unfortunately, this feature is not scheduled at present.

This is important for our organisation as we have multiple workflows, issue types and projects. An issue may be raised in one workflow of one issue type incorrectly, and then need to be moved to an appropriate issue type. Without being able to set the status, the issue may be locked into an invalid or unnecessary status for the current stage of the issue. For example, certain issue types are raised and need approval before work is done on them. Others do not, but moving an issue from a type that needs approval to one that does not necessarily while still at the Awaiting Approval status does not allow the status to be unset.

If I have a step called Open in two different workflows but they have different step IDs, will the wizard force status selection (even if they are called the same)? Having said that, I'd rather not have to re-write and re-publish all my workflows to workaround this, although I'd like to know whether this is an option. Can you confirm therefore whether the status matching is based on step ID, step name, associated status or another property, and whether this scenario would give the desired result?

Thanks

We need this ability since the same statuses have diffrenet meanings in different projects.

Our constant problem is that moved issues get statuses such as "Open" or "In Progress" which are in the "middle" of our workflow. Because of this fact they are undetected by our filters (They lack info that should have been added in prior steps that they didn't go thouh because of the banture of the move) and when detected - we need to manually move them back to the initial status.

[ Show » ] Dikla Tavor [22/Oct/06 07:45 AM] We need this ability since the same statuses have diffrenet meanings in different projects. Our constant problem is that moved issues get statuses such as "Open" or "In Progress" which are in the "middle" of our workflow. Because of this fact they are undetected by our filters (They lack info that should have been added in prior steps that they didn't go thouh because of the banture of the move) and when detected - we need to manually move them back to the initial status.

Seeing as it's been 2 years since this issue was first created, I am not sure it's going to get much visibility but here goes anyway. We would like this feature implemented as a permission (via permission lists). Anyone with the permission "set-issue-status-during-move" could select the target status that was given to issue in either individual issue Move operations or during bulk-moves. This would mean that even if the target status existed in both source and target projects, the person with the designated permissions could still choose to select a different status. Please comment if/when you could address such a change. Thanks.