Redmine

I Created a patch against 3.4 stable to implement copying subtask interrelations.
It applies cleanly to master.
I have been unable to test on master yet due to issues with updating rails (dependency problems for actionpack-xml_parser. Ill do this if I ever get time allotted to continue upstream effort, but as I am doing this as part of my (very busy) day job, I doubt that will happen any time soon, so if anyone wants to take this patch and test it on master, I would be grateful.

This patch is currently working fine on our live 3.4 server.

This unfortunately still applies to the latest redmine-release.

So I made this patch Work for redmine 5.1.3

Can we please fix this defect in main?
Should be an easy fix thanks to the base of Robert Beckett.

This unfortunately still applies to the latest Redmine releases.

I have verified the behaviour against 6.1-stable (6.1.4) and current master (7.0.1 as of 2026-09-29): when copying an issue together with its subtasks, the subtasks are copied, but the relations between them (precedes/follows, blocks/blocked, relates to, ...) are silently dropped. Issue#after_create_from_copy only recreates the subtask tree, not the relations among the copied children.

Attached is a patch (issue_copy_subtask_relations-6.1-stable.patch, apply with patch -p1 from the Redmine root) that fixes this:

• after_create_from_copy now keeps a mapping from each original child issue to its copy (instead of only the ids)
• after all subtasks have been created, a second pass walks the descendants again and recreates every relation whose both ends are part of the copied subtree,
  using the same relation_type relations pointing to issues outside the copied subtree are intentionally left untouched, so no new links to unrelated issues are created
• if a relation cannot be saved (validation error), it is logged and skipped, the copy itself is not aborted

The original idea dates back to a patch we have been carrying against 5.1.3.
This one has been regenerated against 6.1-stable.
It would be great if this could be considered for inclusion in the core, as the current behaviour makes copying template issues with dependent subtasks quite error-prone.

I can confirm this on current trunk. When an issue is copied with its subtasks, the relations between the subtasks are lost.

While testing the latest patch (#17068_issue_copy_subtask_relations-6.1-stable.patch), I found one problem: only relation_type is copied, so the delay of a precedes/follows relation is lost. A relation with a delay of 2 days becomes 0 days.

The attached patch is a reworked version for trunk, based on the previous patches:

• All attributes of the relation are copied, including delay. It works like Project#copy_issues, which already copies the relations between copied issues.
• A single query loads the relations whose both ends were copied. The subtree is not loaded a second time, and the issues are not loaded again for each relation.
• The existing subtask copy loop is not changed. Only a block is added after it.
• As before, relations to issues outside the copied subtree are not copied. Relations that fail validation are logged and skipped.
• Tests are added to test/unit/issue_test.rb. The issue, relation and project copy tests and the related functional tests pass, and RuboCop reports no offenses.