Task due not showing in perspective

I’m a bit confused why the following task doesn’t show up in my “Today” perspective.

But here’s the whole setup:

  1. Project X (deferred until Jan. 1, due Jan. 15)
    The project is set at sequential and Task Y below is the first one.
  2. Task Y in Project X is deferred until Dec. 24th and due on Dec. 27th
  3. The Today perspective is what one would expect:
    • Don’t use project hierarchy
    • Group and sort by Due
    • Filter by status: Due or Flagged
    • Filter by availability: Available
    • Filter context: Remaining

Why doesn’t “Task Y” show up in the Today perspective? (the task is available and it’s due)

I assume the answer is related to the fact that the parent project has a deferred date in the future, thus making all the tasks in the project unavailable, even if individual tasks overwrite the deferred date.

Is there a know pattern on how to manage such situations? A future projects that only needs an investigation sometime before the deferred date.

Yep! But I think the task should show up in the built-in Forecast view (as being due). Does it?

Yep! Defer the Project for December 24 rather than Jan 1.

I might create a top-level @Admin single-action Project. It would contain a task “initiate New Project”. This puts the initiation task outside of the Project itself. The initiation task and the Project can then have different defer dates.



Email Omni and complain about this. I ran into this a long while ago. To me, the idea that OmniFocus would hide a due or overdue action because of being blocked seems misguided at best, and harmful at worst. I can’t think of a single use case where hiding a due action could be helpful to the user. Can you?

I have complained to Omni repeatedly, and they still haven’t fixed it. @kcase said once that they would look at it in the next build, but that was three or four builds ago.

Because OmniFocus will hide due and overdue actions that are blocked, I’ve stopped using sequential projects that have dates. I can’t afford to risk missing an important deadline because OmniFocus is hiding it from me.

Please write to OmniFocus about this, and ask them to make Due/Overdue transcend all blocking. Also, anyone else reading this who wants this to change, please email OMni, because they only pay attention to email requests.

The project x’s defer date of January 1 will override the task Y’s defer date of December 24. Task y is unavailable because the project defer date makes task y unavailable. You should make project x’s defer date be December 24 - the true start date.

Getting the defer dates and the due dates of both projects and tasks can happen very easily. That’s why a review is essential - to catch any errors made in assigning dates. A task’s due date can be blocked by its defer date. Every morning, I wake up to check the review forecast and can easily catch a due today task that was blocked because I mistakenly had a defer date set to after the due date.

I think that the current behavior of OF with regard to defer and due dates of projects and tasks is correct and not a bug. Mis-using the dates is the cause of the omission of the actions in the perspective, not a bug. Such use is inconsistent. When these dates are consistent, the OF behaves as expected.
OF aside, you can’t really have a project that starts later than some action that is part of it. So either adjust the defer date of the project to the earliest date that any acton might start, or re-order the sequence of actions so that the project is consistent, or break out the actions as a separate project.


[…] you can’t really have a project that starts later than some action that is part of it.

While I could understand some of these imposed constraints:

  1. as proven by my post, one can imagine structures of projects that are not necessarily following these constraints
  2. I’d appreciate a tool so much more if it would be able to tell me “hey, this won’t work”

I’m not saying this structure is correct or not. The fact I ended up with it should be a sign that:

  1. there might not be a more intuitive solution
  2. the tool doesnt do a great job at protecting myself from running into an issue (what if this reminder was a critical one and I just missed it? I know that legally there is a probably a disclaimer somewhere in the license making this my and mine alone mistake, but that won’t change my perception on its usability & friendliness)

I have to agree. One of the things I check in my project reviews is whether the deferred and due dates of tasks vs the project line up - its very easy to defer a project to help clear up my views, and sometimes I defer to an improper date.

I cannot think of a single case where deferring a Project or Action Group that has an action that is due before the defer date expires could be anything but illogical. OTOH, I can think of many cases where it is unintentional. That said, I agree that due states should take precedence over defer states.

When you would propose to set up the defer mistake intentionally for some reason …

… you have set up your own bad karma and should live with its consequences accordingly. Finally, you might argue …

… in which case, I’d have to wonder what software tool is ever so well-designed always to protect everyone from every bad karma imaginable.

I’d be happy to see due dates take definitive precedence over defer dates. It would be in accord with OmniGroup’s current approach to show everything due in Forecast, even when the action is three steps down a sequential list inside an Action Group. IOW, here is a case where due date takes precedence over actually being available to do, so why doesn’t due date also take precedence over actually being open to do.


I think mission-critical software like OF2 should be above all things reliable and fault-tolerant. The user should not be able to sabotage their Trusted System by making a simple mistake. Due dates should take precedence over all.

As I mentioned, I have complained about this for years, and it appeared that @kcase paid attention for a few minutes, and then it fell by the wayside. I think this is an issue that needs email complaints; please write to Omni to get this fixed. If you have a more direct conduit to the Omni guys, I urge you to use it.