![]() |
|
#1
|
|||
|
|||
Dependant tasks
Hi
Does anyone have any tricks on how to make dependant tasks. Say I have three tasks. Task 1 Task 2 Task 3 Task 3 is dependant on task 2 being complete and cannot be started until this is true Task 2 is dependant on task 1 being complete and cannot be started until this is true What I want to hide Task 2 until Task 1 is complete and hide task 3 until task 2 is complete. This way I only get to see what can be done, one task at a time. Is there a way of expressing this in a search or some thing like this? Thanks Lazlo24 Last edited by lazlo24; 01-11-2008 at 12:07 PM. |
#2
|
|||
|
|||
Re: Dependant tasks
Quote:
Quote:
About the best you can do is base the your Task Item on the Task Template (or a user created Template derived from the Task Template - then use the (Item) is (Template Name) search expression) - and use the Flag Attribute (Completed -red check). In Tools | Options | Trees - Appearance, select Show Item Flag Icon in Tree (requires restart). Otherwise, you could Search on the Flag Attribute for a given value (flag), restrict the search to a named folder, and Template. See attached file (screen - Wokflow Flag.zip) for some screens that illustrate this. If I've misunderstood we can try again. HTH |
#3
|
||||
|
||||
Re: Dependant tasks
Quote:
It would be dead easy if we had access to parent/children attributes (not just parent title): parent.complete=yes AND complete=no, for example Hope we'll be given access to those attributes sooner rather than later ... |
#4
|
|||
|
|||
Dependant tasks
Hi ashwken
I understand what you are saying but this basically means that I as the user must define what shows up in the search, which is what I currently have to do now. I current have a flag for @next action (Yes it is GTD) which I set to yes when the task is active. What I want to do is program a sequence of events and only have the current and live one visible in the search rather than having to mark off the current one as done and then identify what the next task will be and set that flag. Yes, I guess I am lazy but I like to do all my thinking in one session then switch into 'do' mode where no decisions are made but work is just 'done' as programmed. I see Quant understands my desire for this. This behaviour is exceptionaly useful when setting up a project that has a fixed sequence. I think I may have hit a boundary. Thanks Lazlo24 |
#5
|
|||
|
|||
Re: Dependant tasks
Quote:
Yes, there's a lot of database features that have not yet been made available to the user. As quant pointed out, access to upstream attributes would be useful in this situation and many others. Glad to see that quant has rejoined us. |
#6
|
|||
|
|||
Lazlo24,
UR is definitely a pefect tool for stuffs collection--the foundation of GTD. You may wish to spell out the user interface whereby the conditional events and dependent tasks scheduling should be and can be practically implemented in the UR context. Alternatively, you may use Microsoft Project or ResultsManager for managing events with seamless integration in mind. Armstrong |
#7
|
|||
|
|||
I also use a GTD-inspired setup. I use a Context string attribute to set all next actions (on any type of item), so this normally has values like 'Computer', 'Office', 'Home', etc.
To support cases where something is dependent on something else, I created a context value 'Pending Subtask.' Each of my contexts has a search to show all items assigned to the context, and Pending Subtask is no exception. So I can review these periodically and check to see if the context needs to be changed if all subs have been completed. Also, if I'm working heavily on a project, I often view actions within the context of the project's portion of the tree instead of just the context search, so as I complete things, I can immediately update any parent tasks if needed. Note that I actually create sub-tasks as literal children of whatever item is dependent on the sub-task, as this helps visualize the dependency within the tree. This is very close to the flag approach mentioned above, I just use a different attribute. True, it still requires manual review, but I've never found any way to avoid doing some thinking/review anyway when doing actual work. Of course, I'm not against some future feature that would make dependency easier to accomplish. |
#8
|
|||
|
|||
PureMoxie,
Thanks for sharing your valueable GTD experiences attained through UR. BTW, could you kindly upload a sample GTD urd (devoid of all actual data) so that we can learn from your subtasks structuring? Do you also use UR-suppleid gtd.urd? Armstrong |
![]() |
|
|