[macula]

Originally Posted by Brian

You'll be happy to know that OmniFocus works this way - the cells only show dates assigned to the item itself, but the sorting, grouping, and due soon/overdue statuses all take the parent/grandparent/project/etc dates into account. OmniFocus looks at them all, then uses the earliest date it can find.

If you have a project due Friday, with one action due Thursday and one action with no due date, they'll all behave as you describe. (And if a third action has a Saturday due date set, the project will trump that. When Friday ends, it'll be treated as overdue.)

Indeed, I 'm happy to know that :-)

Just to clarify, in terms of your example above: I understand how the due date of the project would affect the 'free-floating' action and the action that's due Saturday. But would the project (due Friday) itself also 'inherit' the due date of its action that's due earlier (on Thursday)? Or does 'inheritance' work only unidirectionally, from higher-level entities (projects/groups) to lower-level ones?

[whpalmer4]

Originally Posted by macula

Indeed, I 'm happy to know that :-)

Just to clarify, in terms of your example above: I understand how the due date of the project would affect the 'free-floating' action and the action that's due Saturday. But would the project (due Friday) itself also 'inherit' the due date of its action that's due earlier (on Thursday)? Or does 'inheritance' work only unidirectionally, from higher-level entities (projects/groups) to lower-level ones?

I think the underlying philosophy of GTD and OmniFocus is that you always need to have the next action specified, but not that you necessarily have all of the actions specified. To me, that argues for the project due date staying put on Friday, even if the last action with a due date has an earlier due date. Also, what of the case where the project is something like writing a term paper, where the only actions with deadlines are discussing the topic with the instructor to get approval, and turning it in when finished. If you don't actually write down the "turn in the paper" step and just rely on the project's due date, your proposed reverse inheritance would result in the project appearing to be due much too early, and without allowing any time for all of the actions that came after the last one with an explicitly specified due date.

If we flip it around, what would be an example of wanting the project's due date to be pulled forward to the last specified due date, and how would you address the question of subsequent actions that didnt have due dates specified? I suppose one could argue that if the project has the auto-complete flag set, the user isn't planning to add any more actions, but I'm still trying to think of cases where this reverse inheritance would be useful. It wouldn't be welcome for flags, but flags and dates are different animals. Still, having the inheritance working in both directions might be confusing...

Am I correct in thinking you aren't actually proposing it, just trying to explore what is under consideration?

[macula]

Originally Posted by whpalmer4

Am I correct in thinking you aren't actually proposing it, just trying to explore what is under consideration?

Yes, I was just making sure that I understood Brian's clarification—and I hasted to ask before realizing that the 'reverse-inheritance' idea doesn't make sense. Thanks, anyway.

[eurobubba]

Originally Posted by whpalmer4

What's fiddly about it? You look at your projects to decide what is important for the week, right? Just flag those projects as you go down the list. When you get to the bottom, sort the project view by flagged, which will put all the flagged projects at the top. Select them as a group to create the "hot projects" perspective. While they are still selected, you can unflag the whole bunch in the inspector.

No offense intended, but to me that (plus keeping the perspective manually updated as projects are flagged and unflagged) is fiddly. YMMV, natch!