Summary

The purpose of this article is to list the most common reasons why the Next button might be missing from the "Move Issue" screen when trying to move an issue after clicking on More > Move  from the View Issue screen, as illustrated below:

Normally, the Next button should be visible next to the Cancel button, as illustrated below:

Environment

Jira Server/Data Center on any version from 8.0.0.

Diagnosis

• Open the impacted Jira issue and check if it has sub-tasks (this KB article is only relevant if this issue has sub-tasks)
  
• Open each sub-task and check:
  • If at least one of them is archived, as illustrated below:
    
  • If at least one of them is not archived, but is missing the option to be moved from the More menu, as illustrated below:
    
• If you found at least 1 sub-task that is archived, then the Root Cause 1 is relevant and you can move on to its respective resolution section.
• If you found at least 1 sub-task that is not archived, but for which the Move option is missing from the More menu, continue with the steps below:
  • Try to edit the workflow configuration associated to this issue
  • Click on the Properties link associated to the status the sub-task is currently in
    
  • Check if the property jira.permission.move.denied is listed as illustrated below:
    
  • If you see this property, then the Root Cause 2 is relevant and you can move on to its respective resolution section.

Root Cause

If a Jira issue has sub-tasks underneath it (=it's a parent issue), this issue can only be moved if all its sub-tasks can also be moved. If there is at least 1 sub-tasks that is not "eligible" for the move, it will not be possible to move the parent issue and the Next button will be missing from the screen.

There can be various reasons why a sub-task cannot be moved.

Root Cause 1 - At least one of the sub-tasks is archived

When using Jira out-of-the-box (without any 3rd party add-on installed), archiving a sub-task without archiving its parent is not possible (we do have an open feature request https://jira.atlassian.com/browse/JRASERVER-70638 to allow this behavior though).

Some 3rd party add-on such as ScriptRunner might bypass this Jira restriction and allow users to archive a sub-task without archiving the parent issue, as described in the KB article Some Jira sub-tasks are archived without their parent issue being archived. When this happens, the parent issue ends up in an "inconsistent" state, since:

• the parent issue is active (it's not archived)
• the sub-task issue is archived

In such situation, it will not be possible to move the parent issue since its sub-tasks cannot be moved (archived issues cannot be moved/edited...). As a result, the Next button will be missing from the Move Issue screen of the parent issue.

Root Cause 2 - At least one of the sub-tasks is in a status that has the property "jira.permission.move.denied"

Workflow statuses can be configured with workflow properties that add some restrictions to any issue that is in that status. One of the property is called jira.permission.move.denied and blocks users from moving an issue to any other project or type.

If a sub-task is in such status, the following will happen:

• this sub-task cannot be moved (the Move option will be missing from the More menu on the View Issue screen)
• its parent issue cannot be moved either, and the Next button will be missing from the Move issue screen of the parent issue)

Solution

Solution for Root Cause 1

By design, it is not possible to restore a sub-task on its own. For this reason, you will need to follow the steps below to un-archive (restore) all the sub-tasks located under the parent issue:

• Open the parent issue of the archived task
• Archive the parent issue via the menu More > Archive

Once all the sub-tasks have been restored, you should be able to see the Next button in the Move Issue screen.

Solution for Root Cause 2

There are 2 possible options:

• Either move all the sub-tasks that are in the status configured with the property jira.permission.move.denied to a different status
• Or remove the property from the status in the workflow configuration, in case this property is no longer needed (make sure to publish the workflow after you do so)