Feature Request: Allow bulk conversion of issue types (Task → Sub-task) and parent reassignment via

Hi @Manuel Walker, the bulk move endpoint does this today. The reason it looks missing is that the target parent is not a field in the body at all. It sits in the mapping key.

POST /rest/api/3/bulk/issues/move. The reference gives that key as <project ID or key>,<issueType ID>,<parent ID or key>, and says the parent slot is "Only required when the destination issueType is a subtask". So your five go in one call:

{
  "sendBulkNotification": false,
  "targetToSourcesMapping": {
    "EVD,<subtask-type-id>,EVD-205": {
      "inferClassificationDefaults": true,
      "inferFieldDefaults": true,
      "inferStatusDefaults": true,
      "inferSubtaskTypeDefault": true,
      "issueIdsOrKeys": ["EVD-200","EVD-201","EVD-202","EVD-203","EVD-204"]
    }
  }
}

The middle slot is the numeric work type ID rather than the name, and GET /rest/api/3/issuetype/project?projectId= gives you the sub-task one for EVD.

You get a 201 with a taskId, then poll GET /rest/api/3/bulk/queue/{taskId}. Status can land on FAILED or DEAD as well as COMPLETE, and the same response carries invalidOrInaccessibleIssueCount and failedAccessibleIssues, which is where anything that quietly dropped shows up. I ran this today on a Cloud site, one company-managed project and one team-managed, two Tasks in each, and both finished COMPLETE with the Tasks reading back as Sub-tasks of the parent. One target parent per call though. I tried two mapping keys with two different parents in a single payload and it came back 400, "You can only move issues to a single target project, issue type, and parent issue", so a deep tree is one call per parent. Permissions are the global Make bulk changes, plus Move in the source project and Create in the destination.

The single-issue edit genuinely won't cross that boundary, and that part is by design. Atlassian tightened the validation in August 2022 on JRACLOUD-68207: "The REST API fails if one of the source and target issue type is subtask, but the other one is not." JRACLOUD-27893 is still open for the single-issue version of what you want.

The UI isn't one at a time either. Bulk Change, then the Move work items operation, handles work type changes inside the same project, and picking a sub-task type there makes it ask you for the parent.

Hi @Manuel Walker 

There is already an open feature request fro this, see JRACLOUD-27893 

Note, You could also use the Feedback button within Jira under the Help button (near your avatar in the upper right corner) to provide that suggestion directly to Atlassian.

Feature or feedback on the public forum is not recognised and will mostly drop away silently.

This forum is public and for users this is not a main support channel.

Hi @Manuel Walker,

Worth knowing that the UI side isn't limited to one work item at a time either, so if this is a one-off restructuring you may not need the API at all.

From the List view (or the backlog or board), select the work items, then More actions (•••) and Bulk change work items, choose Move work items, and on the destination step pick the same space with a different work type. That is the supported path for changing work type in bulk. You then map statuses if the target work type uses a different workflow, and set or Retain any required fields before confirming.

Two constraints are worth planning around before you run anything, because they will bite a bulk operation in the middle:

• A work item can't be converted to a subtask while it still has subtasks of its own. Those children have to be converted to standalone work items first, which means your restructuring may need to run in two passes, deepest level first.
• Subtasks also can't be moved straight from one parent to another. They have to be converted back to a standalone work item, then to a subtask of the new parent.

So for a tree like yours, the order that works is: flatten any existing subtasks under EVD-200 to EVD-204, then convert those five to subtasks of EVD-205, then re-attach their former children.

On the feature request itself, the Jira ticket for it is worth watching, and Atlassian's in-product Give feedback form under the Help menu tends to get more traction than a forum post.

Best regards,

Ivan