See the first T1 task. I’m showing that task in the process of assigning duplicates (to one assignee), but I actually already clicked “Assign task” and that resulted in the second T1 task you see in the screenshot.
Notice that the first S1 (the model to be duplicated) has set Assignee, Due date and Critical.
Notice that the duplicated S1 (the second one) doesn’t persist the subtask Assignee.
Why not? This is a defect. (Unless I’m missing something.)
It’s also causing a pain point for an Enterprise client’s complex grant workflow that I designed and we’re trying to implement.
Hi @lpb, thanks for tagging us! This is actually the expected behavior to prevent subtask assignees from receiving multiple copies of the same subtask, especially when assigning duplicates to an entire team. If the subtask assignee persisted in all copies, they could end up with dozens of identical subtasks, which is not typically desirable.
Custom fields and other details are retained because they don’t cause the same impact.
I’ve seen similar feedback before, where users requested an option to automatically assign subtasks in copied tasks to the same assignee as the parent task, but this isn’t possible yet either.
I understand the intent, but it’s unexpected to many of us. It may help sometimes, and it may hinder sometimes. And it’s inconsistent: When you Duplicate a task, it doesn’t remove subtask assignees, so why do Duplicating and Assign Duplicates not work similarly? I don’t think that’s defensible!
I’d like to see either of these two changes:
Don’t “help”; if I’m assigning duplicates and have left a subtask assignee in place then honor that, don’t silently remove that, or
Show a dialog that offers the choice of removing subtask assignees or not. That would be consistent with Duplicate task and Duplicate project which both offer dialogs.
