+1 on having the dependencies of a task created from a template with internal dependencies, to have them point to the new project's tasks instead of the original template's tasks.
In the meantime, if the dependencies are really that much of an issue then the alternative is to use the template as the project. You can then create a recurrence for the top level of the "template turned active project" solely to be used to recreate the project when you are finished with it. Steps to use the project would be: uncheck the "hide branch in TODO list" of the project create recurrence for top level tree (lets say "yearly" regenerate 1 year) Use the now active project and when complete it will recreate itself for a year in the future... Now to put the "future" project back in storage: In recurrence "remove recurrence" uncheck "Due Date" and "Start Date" check the "hide branch in TODO list" And it is now ready for re-use at your leisure... On Nov 30, 4:29 pm, Gaston <[email protected]> wrote: > Hello there, > > I will try the conditional workaround you propose and let you know how > it works for me. With regards to the dependencies, I also tried to > keep a template directory but my projects have over 30 dependencies > within them and I need to activate them pretty quickly and start using > them right away. Fixing the dependencies is just not an option. > > Thanks again. > > Gaston > > On Nov 30, 5:11 am, nschm873 <[email protected]> wrote: > > > > One of the worst setbacks I've found is the > > > fact > > > that dependencies cannot be exported in MLO or set up to be relative > > > to a task. > > > I do this differently with partially better results. I create a top > > level directory called "templates" in my existing outline that I have > > marked "hide branch in the TODO list." Now when I copy a project from > > the templates hidden tree to an active tree the dependencies are all > > there. They just point to the task in the templates project not the > > active projects. This means you still have to go into the newly > > created project and "fix" the dependencies. However, this is much > > easier then creating them from scratch. > > > MLO has an icon on the right side of the icons column that show > > dependencies. You just need to go to those tasks that have that icon > > and point the dependency to the newly created task. The name you need > > to use is there already so it is simply adding the new dependency with > > the same task name in the active project branch and then deleting the > > old dependency of the same name. > > > >For example, a task that can be answered Yes or No and that would > > >trigger a different set of tasks to be activated or deactivated. > > > As for the conditional tasks, I don't see why you can't manually do > > that. If you create a "conditional task" you can have two trees under > > that branch. If you are using a copy of the original project then you > > can just delete the branch "this time" that you don't want to use. > > > If you are using a recurrent project then you can simply mark the > > other branch using "complete task and all subtasks". That ability is > > located by right clicking on the task and going into the advanced > > feature. There really aren't any repercussions that I can think of to > > mark a subtree of a project completed since MLO only logs the project > > being completed. > > > Also you can highlight your "conditional" tasks with an automatically > > created icon. In the automatic formatting rules add a rule that > > displays a question mark based on something in the caption such as the > > word "condition". Then you will get a question mark in the icons > > column for any task with the word condition in it. Now it is pretty > > easy to see which tasks are your "conditional tasks" and you can then > > manually "trim out" the subtrees that you don't want to use. > > > So basically one pass of your newly "recreated" project to fix the > > dependencies and another pass to fix your conditional "choices" and > > you are good to go. > > > On Nov 24, 3:05 pm, Gaston <[email protected]> wrote: > > > > Thanks Lisa, > > > > I actually thought of that. but it's just too much trouble. I've > > > noticed that there are a chunk of processes that stick together and > > > need to be done in succession. The ability to branch would be really > > > useful. > > > > Also, because of the nature of the projects, dependencies are > > > extremely important. One of the worst setbacks I've found is the fact > > > that dependencies cannot be exported in MLO or set up to be relative > > > to a task. Which means that I cannot create a "master task list" full > > > of dependencies and re-use it without having to set up the > > > dependencies all over again. > > > > I absolutely love the way MLO handles the tasks in the To Do list. I > > > would love to have that tool to guide me through my daily tasks at > > > work, but I sincerely don't have the time to plan projects from the > > > ground up every time around. > > > > Rgds, > > > > Gaston > > > > On Nov 23, 5:12 pm, Lisa Stroyan <[email protected]> wrote: > > > > > >For example, a task that can be answered Yes or No and that would > > > > >trigger a different set of tasks to be activated or deactivated. > > > > > It would be a bit kludgy but you could have two tasks, the "Yes" task > > > > and the "No" task (which I believe could be hidden from the Todo > > > > view), and then a different set of children tasks that are dependent > > > > on each of those, so they only show up if Yes or No is completed > > > > (checked). > > > > > Of course later you would want to delete all of the other branch, > > > > which would be a pain. > > > > > Lisa > > > > > ---------- > > > > Lisa Stroyan, mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "MyLifeOrganized" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/mylifeorganized?hl=en.
