[korm]

I have actions that were due last week. So, under the context view, when grouped by "due", they show up in the "due within the last week" group. They display in red. Makes sense. They are past due.

However, if I change one of those actions to be due today or in the future, it remains within the "due within the last week" and red. Doesn't make sense. It is no longer past due.

Seems that the only way to get the action into the right state is to delete and re-add. Why shouldn't I be able to re-plan an action to a future date?

I'm confused. What am I missing?

Paul

(this is 96712)

[Dirk]

Perhaps the actions you try to change are childs of other actions? If the parent-actions have former due-date, the due-date of the childs are overwritten. That could be the reason, why they stay red …*without parents they should change immediatly colour and due-location.

--Dirk

[korm]

You are correct. The parent project had a past date due date, and so the items remained red. However, it seems counterintuitive that the context-based perspective grouped by period would show the actions "due within the last week". Regardless of the project due date, the individual actions are not past due.

That might be logical, in a fashion, but it doesn't seem helpful. Is that really how GTD is supposed to work?

[curt.clifton]

This isn't a function of how "GTD is supposed to work". The Getting Things Done methodology isn't that specific.

This is a consequence of the fact that children in OmniFocus are assumed to be the actions necessary to complete their parent. (You may have different assumptions about the relationship of children to their parent, but if so you'll find yourself working against the tool.) Based on OmniFocus's assumption, it makes no sense for the due date of a child to be later than the due date for the parent. OF partially enforces that assumption by marking the children as overdue if the parent is overdue. Stronger enforcement would disallow setting the due date on children later than the due date on their parents. There's been some talk about doing that, but it would make some editing operations more cumbersome.

[korm]

I'm not making my point clearly. It relates to a specific scenario:

If I am looking at actions in context view, grouped by "Due", then I shouldn't see actions that are set to be due in the future listed in a group headed "Due within the last week".

That is a goofy result, which makes me distrust OF and wonder about other data sorting and selection logic in the product. I don't think that is "working against the tool", I think it is the tool being flat out unhelpful.

[pvonk]

I would hypothesize that an action due in the future and belonging to a project this is overdue should raise a red flag. Something is possibly wrong. If the "grouped by DUE" were to drop the action in some future bin, it may be missed. If it shows up in "past due" then the user would be alerted and he could then decide if there's a date mistake or not.

I'd rather have some strange situation show up as abnormal in some way (so I can then determine whether I've made a mistake or whether the project due date needs updating) than have it appear as normal.

[ptone]

Originally Posted by korm

If I am looking at actions in context view, grouped by "Due", then I shouldn't see actions that are set to be due in the future listed in a group headed "Due within the last week".

This makes sense when you look at in the from the POV that the due date for a task is earlier of the tasks due date, or its project due date - whichever is earliest will rule.

I think where OF falters on this, is the app should prevent you from assigning a due date for a task later than its parents due date. When that situation comes up, there should be an alert detailing the issue:

When setting a task on a dated project: "This date is later than the projects due date and will be set to the due date for the project"

When setting a date on a project with dated tasks: "N Tasks have due dates later than this date, proceeding will change all later dates to this date" Proceed/Cancel

That would really help the user know what is going on in OF object model a bit more.

There are a still a few places where OF lets the user go down a road of dead ended expectation.

-P

[Ken Case]

Originally Posted by ptone

I think where OF falters on this, is the app should prevent you from assigning a due date for a task later than its parents due date. When that situation comes up, there should be an alert detailing the issue:

Yes, exactly. We plan to handle this in much the same way as we do in OmniPlan (with an interface that lets you choose how you'd like to solve the conflicting data, but doesn't force you to choose one or the other right that instant), but this interface won't be in Tuesday's 1.0 release.

[Lizard]

Forgive a stupid question. Does clicking the Clean Up toolbar button move the action out of the overdue group?

[pvonk]

>"I think where OF falters on this, is the app should prevent you from assigning a due date for a task later than its parents due date. When that situation comes up, there should be an alert detailing the issue:"

However, isn't it possible that one of the tasks, perhaps reminding you to send a thank you after the project has been completed, might have a due date after the project? How are we to predict every possible case? Shouldn't OF be general enough to handle such unusual situations?