Duplicate Task in Two Places

[Darryl Brooks]

Have searched on this and haven't found an answer. Is it possible to place the same task in two different locations (folder, project, etc.) so that if it is completed in one, it is completed in both. In other words, it is physically the same task, but falls under two different areas. I tried to copy a task between two folders and it didn't work. 

Is there a workaround on this? 

In my case, I have a folder for Morning Routine. There are a great many tasks I do in the first few hours each day. But each task also belongs to different functional areas, so I would like them to appear in those folders/projects as well.

Any help appreciated.

[Alyona (MLO Support)]

It is not possible to have the same task in several places in the Outline. Instead of placing tasks into a folder for Morning Routine, you may assign contexts like @Morning Routine, @Daily Routines, @Errands etc to your tasks. One task may have multiple contexts. Then open a view with tasks grouped by context and you will see that the same task appears in several groups.

More about contexts in the manual

[Craig Lindholm]

I also would like this. I have multiple projects that rely on the the same task being completed. Maybe in the future, we could have a "soft link" to a task.

[Stéph]

It would be pretty complicated to have the same task appearing in multiple places in one outline, I think. Darryl, would Alyona's suggestion of using contexts work for you? 344cl, have you tried using "dependencies" and the "complete tasks in order" option to flag up that common tasks need to be completed before a project can proceed? Would it work to have your project folders as subfolders of a "common project tasks" folder? Something like this:

>Folder: Common project tasks (or project group tasks, or programme tasks)

>>common task 1

>>common task 2
>>>Project 1

>>>>project 1 task 1

>>>>project 1 task 2

>>>Project 2

>>>>project 2 task 1

>>>>project 2 task 2

[Joel Azaria]

Not as complicated as you think as it's been done already and for decades.

1 very pervasive example is computer file systems (mostly Linux though Mac and Windows have it too, just more obscured from view to the typical end-user).

A file system after all is just a tree, exactly as our outlines are.   File systems like that support a concept called "links"   There are "soft links" and "hard links" which have some differences but the TLDR is that they act as virtual pointers to another part of the tree / file system.   To use your example:

>>>Project 1

>>>>project 1 task 1

>>>>project 1 task 2

>LINK>project 2 task 1

>>>Project 2

>>>>project 2 task 1

>>>>project 2 task 2

Project 2 Task 1 (and it's descendants) will SHOW under Project 1 even though it may ultimately "live" under >>>Project 2.   The link is, in effect, a virtual "doorway" to the other location.    This does not violate the integrity of the tree structure in any way and, as I've said, tree structures like Linux's EXT3, EXT4, Mac's HPFS, Windows' NTFS, as well as ZFS, BTRFS, and other high performance file systems have done this for literally DECADES.  This is not uncharted territory.

There are multiple use cases where I've wanted/needed this functionality.  Contexts are not a substitute as there are times that something belongs in the tree in multiple places, not just "presented" that way in a flat viewport.  This is usually a project planning or overview situation but I've encountered it in other places.

Another simplified example might be a shopping destination that exists both in your work and home tree structs.  I can go to Home Depot for either reason.   I don't want two separate "Home Depot" nodes (with their associated contexts, etc.) to live in two places.  I want "Home Depot" avail in two places so I can list my work stuff here and my home stuff there.  Yes, I will use a view based on Contexts for actually SHOPPING but for PLANNING, I want HD in two places in the tree.

[zel...@gmail.com]

Another workaround would be to insert a link in the Task Note. See 5.1.7.1 on page 35 of the manual.