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

Question

Feature Request: Allow bulk conversion of issue types (Task → Sub-task) and parent reassignment via REST API Summary: It is currently not possible to programmatically convert a Task to a Sub-task and assign it a parent via the Jira REST API or automation tools. This operation is only partially supported in the UI (one issue at a time) and completely unsupported in bulk. Use Case: When structuring a project hierarchy (Epic → Task → Sub-task), users need to reorganize existing Tasks as Sub-tasks under another Task. For example: Epic: EVD-611 "xxx" └── Task: EVD-205 "xxx" ├── Sub-task: EVD-200 "xxx" ├── Sub-task: EVD-201 "xxx" ├── Sub-task: EVD-202 "xxx" ├── Sub-task: EVD-203 "xxx" └── Sub-task: EVD-204 "xxx"Current Limitation: * The PUT /rest/api/3/issue/{issueKey} endpoint does not reliably support changing issuetype from Task to Sub-task while simultaneously setting a parent. * Bulk operations via the API fail silently or reject the request. * Users are forced to manually convert each issue one by one in the UI. Requested Improvement: * Allow issue type conversion (Task ↔ Sub-task) via the REST API in a single update call * Support bulk conversion of multiple issues in one operation * Expose this capability to automation tools (Rovo, Automation for Jira, etc.) Impact: Project managers and engineers structuring work breakdown hierarchies are blocked from efficiently reorganizing their backlogs. This is especially painful in manufacturing/engineering projects with deep hierarchies.

Ivan Manolov _Appfire_ · Answer

Following up on my earlier answer, @Manuel Walker, on the reassignment half of this: if you're open to solutions from the Atlassian Marketplace, the app my team and I work on, JXL for Jira, makes reparenting a bulk edit rather than a scripted operation.

JXL is a spreadsheet/table view for your Jira data. With a hierarchy enabled, you select several rows and drag them onto a new parent, and JXL updates the fields that define the hierarchy for all of them. You can equally paste a column of parent keys onto the Parent column, the way you would in Excel.

To be clear on the limits: JXL edits fields, so the Task to Sub-task conversion itself is still Jira's move operation, not something JXL performs.

That said, it's worth asking whether you need the conversion at all. JXL's custom structures can build the hierarchy level by level, including levels linked by work item links rather than the Parent field, so a Task can sit under another Task in the view without either of them becoming a subtask. For manufacturing-style breakdowns that avoids Jira's subtask nesting limit entirely.

All the best,

Ivan

Ivan Manolov _Appfire_ · Answer

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

Gabriela - LeanZero · Answer

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 ,,, 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,,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.