Clear "due within container"?

I’ve got a repeated “Review” project with nested projects (Those child project are pretty long lists).

This review project has a due date and what is very irritating is the fact, that all the chid tasks are added as due to my calendar. So I’m ending up with over 50 items on the same time in my calendar as a reminders. Is there any way to have a reminder only for the “parent” project?


I’m having the same issue as well. Could someone suggest a workaround?

1 Like

I don’t think so, because the logic follows that if a project (outcome) is due on a certain date, then all the tasks that would see that through to completion must therefore also be due.

In this case, I might make a separate meta task to “Review the Review Project”, perhaps as the first child of that project, and have that task be the due one, and remove due dates from the Review project itself.




I have the same issue! It would be very nice to have the function to disable the function, that the tasks inside a container are due with the container. My whole Forecastview is being messed up in this way!

The workaround from @deturbulence is nice, but still in this way, I cannot “work” within the forecast view. Rather I have to switch to the project view constantly and this is very annoying! I recommend you guys to write a mail to the support, as I did before. Maybe something will change.

1 Like

Do others also have the same issues?

1 Like

For those who are interested:

The Similar Topic is being discussed

Here - Stop Child tasks to inherit Due Date of Action Group

Here - Preventing tasks with inherited due dates from showing in Forecast

1 Like

This is not logic, this is a poor software decision.

1 Like

I think Omnifocus never thought about it deeply. But as far as I hear from they support, they are aware of this request. So everybody please write them an E-Mail so we can make our voice being heard. I don’t think that it is a lot of work to implement, event though they are working on OF3 for Mac right now it might be something they could implement.


I’m writing an email as well.

1 Like

If I had a project, though, that is, say “Get to work on time”, and it was due for tomorrow at 9:00am, then logically, I’d have had to also:

  • wake up
  • get showered
  • get dressed
  • eat breakfast
  • get in to car
  • drive to work

… also all done by 9:00am, or else I wouldn’t be able to meet the conditions of the project.

I can make each of these due sooner than tomorrow at 9:00am, sure, but if the container/project is to be achieved on time, I’d also have to complete the actions that result in that outcome by that time. This is why actions inherit the due date of their projects/containers.



If it’s genuinely a project, then it is very logical (as someone else has pointed out. If it’s just a container for a bunch to actions, don’t give it a due date.

I think the idea of being able to suppress child tasks in some view is good - but that doesn’t mean the existing process is bad


Looks like several other folks have now chimed in, but I’ll just confirm that yes, it’s part of the design of OmniFocus that when a project is due, every separate item within that project is due. Otherwise, you could end up looking at one of the tags for one of those items and not realize you had something due that needed to get done on that date!

I agree that if you have 50 items in your project, that’s a lot of tasks coming due at once. But that’s exactly the sort of situation project planning software is supposed to help you notice! If you see you have a bunch of things coming due on the same day, I’d strongly suggest setting earlier due dates on some of those items so you know that you need to get them done on earlier dates rather than having everything come due at once.

(If there are items in that project that really don’t need a due date at all, then I’d suggest moving them into the project’s notes rather than listing them as separate tasks. As items in the project’s notes, they will no longer be listed as independently due items.)

I hope this helps explain the logic behind the design for those who might not have understood why we built this the way we did!