[psidnell]

I thought I new OmniFocus pretty well - but today it surprised me.

If you have a context hierarchy like this:

Work
- Going to Work
- Arrive at Work
- ....
- Leaving Work

And you pause the Work context, would you expect all the sub contexts to be paused? I did but apparently not.

On the the other hand dropping a folder takes all sub folders with it and flagging a project/task flags all it's child tasks.

Objective: I was looking for an iOS friendly strategy for quickly disabling or enabling all (eg) work related tasks over the weekend or prior to going on holiday.

On the desktop it's easy to select all tasks in my work context and set a start date of Monday but not so easy on the phone. Also the start date strategy is hard to undo and can mess up carefully crafted repeats. If folders were pausable that would be an option, but they're not.

I'm curious - does anyone have a use for paused root contexts + unpaused child contexts?

[Dale]

I have never thought about having a hierarchy (whole or part) of a context which would be "On hold", and as such never attempted or expected contexts to work in this manner. From reading your remarks; the question seems to stem from the solution to manage the visibility of tasks by frequently manipulating elements based on visibility, rather than identifying when or how the tasks can be completed. I would suggest an alternative method in managing your viewable tasks within OmniFocus.

You could create a custom perspective for "Work" and "Home" tasks/projects. The use of a custom perspectives allows one to setup the view for subsets of tasks instead of using start dates to postpone such tasks or temporarily placing contexts on hold to remove them from view. On your iOS device you can view these custom perspectives and this would allow you to see only "Home" tasks without the "Work" tasks or visa versa.

[psidnell]

Originally Posted by Dale

...
You could create a custom perspective for "Work" and "Home" tasks/projects.
...

I do actually have perspectives that do this but even though they work on the phone they're less flexible than using the native context view. You can't navigate around the contexts in a perspective on the phone or change the view settings the way you can in the context view - hence my search for a way to just simply "turn off" categories of stuff until I'm ready for them again.

For anyone interested in further exploring the slightly bonkers behaviour around context status try creating this context structure:

Root
- Sub1 (paused)
- Sub2

Pausing Root leaves Sub2 active.
Dropping Root makes Sub2 dropped (but a lighter colour, same as flagging).
Dropping Root and un-pausing Sub1 makes it dropped.

I'm still note sure if this is a bug or a feature :-)

It looks like I could achieve what I'm looking for by dropping instead of pausing since dropping cascades to sub contexts but pausing does not - except that the help injects some doubt:

If there’s a context you don’t intend to use anymore, such as the office for a job you left, or a person who transferred to a different department, you can drop it. All of your old actions that were assigned to it stay assigned to it, but the context doesn’t appear in your Remaining contexts sidebar. Any remaining actions still assigned to a dropped context become unavailable and move to the No Context group of the context mode sidebar.

The last statement seems to imply that uncompleted tasks move context - but this doesn't seem to happen when I test it, they just stay put.

The behaviour does seem unexpected, at least at first glance.

The context table in the cache has an effectiveActive field, which suggests at least some history of status inheritance in the design.

(The context object in the Applescript library has an effectively hidden flag).