Prevent the Move Process

[Jens Prokoph]

Problem:
2 sections -> When changing the “Work type,” this can be done without any issues in Project 1, and no further prompt appears after selecting the second work type.

I want this to work the same way in the second section, but when I try to make the change, the following dialog box appears:

What could be causing this, and how can I fix it?

[Avinash Bhagawati]

HI @Jens Prokoph Good day!

In this case, Service Request and Incident issue types ( Work types) may having the different workflow mapped to it. If the workflows are different, then you need map the statues in the move screen.

Please check your own workflow mapped both Service Request and Incident.

Thanks,
Avinash

[Sami Shaik]

Hello @Jens Prokoph ,

I tested this today in a company-managed service project, and there are three levers here, depending on what exactly you want to prevent.

Lever 1: align the workflows, and the wizard stops appearing. The "Move Issue" wizard is not random: it only triggers when the work type you are changing FROM and the one you are changing TO sit on different workflows. Jira has to ask you to map statuses because the two types don't share them. Map both work types to the same workflow in the project's workflow scheme and that requirement disappears: the type change becomes inline, no wizard, no status mapping, for everyone, permanently. This is the right fix when the dialog keeps interrupting legitimate changes your team makes every day.

Lever 2: remove the Move Issues permission, and nobody moves at all. If the real problem is that people should not be doing this in the first place, it is a permission question, not a workflow one. In the project's permission scheme, remove the Move Issues permission from the roles that shouldn't move. Tested today: the Move option disappears from their actions menu entirely, and if they try the work type icon instead they see "You cannot edit this work type in this space." No wizard, no way through. Two admin cautions: permission schemes are often shared across projects, so copy yours before editing, and a move also needs Create permission in the destination, which acts as a quiet extra gate for sensitive projects.

Lever 3: change the request type instead, and the move process never starts. JSM gives you a path the other two don't need config for: changing the request type within the same underlying work type never triggers the move process at all (also verified today). It is only the work type change across different workflows that does. If your agents are mostly re-categorizing tickets, a small habit change, request type instead of work type, avoids the whole problem without touching a single scheme.

Short version: same workflow = no wizard, permission scheme = no movers, request type change = no move at all. Pick the lever that matches the behaviour you're trying to prevent.

[Marc -Devoteam-]

Hi @Jens Prokoph 

This depends on the workflows used by each work type in a space or within a different space if you move work items to another space.

On moving work items between spaces they can also differ or even use different screens, so field information can be lost, as the fields don't apply within the other space.

This is what the information bar is telling you, it's informational message.

If you continue you will notice if such implications are in order.

The 1st option you did, is only possible if the workflows of both work item types align, so the same flow is used or the flows for each type are equal.

If not, then you get the view, you mention in your 2nd option.