#1
|
|||
|
|||
Search child item attribute
In my GTD implementation using UR I like to include inactive future tasks that are dependent on an earlier task being completed.
Active tasks appear at the lowest level of the tree. As they are completed, they are removed (or relocated) and the next task 'up' the tree becomes active. A search for task items with no children brings up only active tasks. I can then sync these with Outlook and my PDA. A difficulty I have run into is that I also like to keep emails and other files related to a task (GTD 'support' material) stored with the related task. The most convenient way to do this is for the support material to be included as a child item of the task. This has the advantage that when I remove or relocate the task item the attached child files are removed as well (great for filing etc). But if I do that the 'no children' search is no longer any good for bringing up active tasks. One solution that has occurred to me would be for additional searching capacity to be added to UR enabling searches of an item's child's attributes (or some of them) - eg: child item template does not equal 'task'. Naturally if anyone has an idea as to how I might get around this problem with UR's existing capabilities I'd be grateful for their views. |
#2
|
||||
|
||||
interesting ... mainly because by doing GTD (or whatever) this way, by changing state of one item (by deleting it), you are changing the state of the related item automatically. This is very powerful!
At the moment, you could maybe only link the emails inside the task (wiki link), and store all emails in the "email repository" directory. But it's true that it would be nice if you could store various items related to the task as their children, so I support your search request feature for "child item template does not equal", unless someone else has a better idea |
#3
|
||||
|
||||
A quick bit of brainstorming...
How about enhancing the existing Search Item so that it has two tabs? Each of these tabs to contain it's own "search criteria rows". The tabs being labelled something like [Main] and [Child]. When doing an advanced search, the criteria in [Main] is applied first. The [Child] criteria is then applied to the immediate children of those items found by [Main]. (1) If [Main] criteria specified but [Child] is NOT, then searching works exactly as it does now. (2) If [Main] criteria NOT specified but [Child] criteria is, then all (or limited) items in database checked for immediate children matching the child criteria. (3) Font of each tab to be bold when any criteria rows present and dimmed when no rows present. |
|
|