There are several changes to OmniFocus going into version 1.8. As of this writing, it is still in itsSneaky Peek versions so things may change.

I’ll go over a couple of points of interests:

• alterations to the filtering options and
• a change in how group tasks and projects behave in context view.

There may very well be other important points to review as even small changes can have large impacts that are not immediately apparent, while others I just won’t focus on. For example, I do not go over changes to the Attachment List. For me, the attachment list is only useful in so far as I try to keep it empty.

If you find something in the release notes or elsewhere that is worth special noting, please comment.

Filtering Option changes

• The due and flag options have moved from the Availability Menu to the Status Filter Menu,
• There is a new “Due and Flagged” option,
• An “Any Status” option has been added to the Availability Filter.

One example of what this means is seen if you rely on flags as a method of bringing most tasks to attention (instead of start dates as the treading water perspective does). You can now use the “Due or Flagged” option alongside “Available” to create a single master list of:

• Routine maintenance tasks,
• Tickler items,
• Due soon tasks, and
• Anything else that is flagged and available.

In order to do so, you would be using flags on the routine maintenance tasks and tickler items in addition to projects that were deserving of immediate attention. Jesse commented of a version of this. A filter configuration might be:

In 1.7.5, a similar view could be obtained by using a Status Filter of “Available” and a Flagged Filter of “Flagged”. However, this view would not include due soon items. Moving the due soon and flagged options in 1.8 allows for further integration of the lists.

Projects and Task Groups

Projects and Task Groups are now potentially available in the context view. The potential arises from whether or not they have automatic completion checked or unchecked (accessible via the inspector «Shift-Command-i»).

Those that do not automatically complete now appear in context view after its children are completed. In other words, the parent task or project is blocked by its children until they are created.

This allows one to review the project or group before deciding it is complete directly in the context view. Prior, this would be done from the Project Mode, typically, during a review. Now it can be done immediately upon completing a final task.

However, one still has to be aware of how the parent task may appear in the usual view. If for example, you are using a view dependent upon start dates such as treading water, then a parent task such as:

would not appear in the context view as it has no start date. Rather, the start date would need to be entered on the parent task:

This would show the child task first and, when checked, the parent task would appear. The same principal applies if one uses flags or due dates as methods for bringing tasks to attention in the context view.

When I first installed the sneakypeek, I was met with over 200 “no context” group tasks and projects. After a moment, I realized that these were simply unassigned defaults for those groups and projects.

You may wish for projects to function as they have in the past and not appear at all in the context view. If so, the release notes provide the suggestion of assigning a “Review” context to projects and place that context On Hold. The drawback to this, however, is that you lose the convenience of a default context for new tasks within projects.