BUG or FEATURE in latest 1.8 sneaky peek?
 

At least in the latest OmniFocus beta version (v77.62 r137400, released 19 August), if the parent of an action group is given an unavailable "on hold" context, the children actions remain available.

Is this a feature or a bug?

Thank you!

I would opine that it is not a bug. Remember that the context for an action group (or a project) is merely the default context to be inherited by any child rows that do not have a context specified when entering them, and thus has no bearing on the availability child rows if they have other contexts specified.

Can you give an example of why you would want the action group's context to affect the availability of the actions if they had other contexts?

Thanks, Bill.

That putting a parent 'on hold' would make its children unavailable seemed to me so natural that I forgot the 'feature' that you mention: Indeed, the 'context' field for groups is merely a default context for new children.

As for a usage scenario, quite straightforwardly, I wanted to defer an action group indefinitely to the future—i.e. to put it 'on hold' :-)
It only seemed natural to me to put the parent task 'on hold' rather than changing the context of each child.

Consider that some of the children may be action groups themselves. In such a case, "putting the children on hold" means that the lowest-level actions (the "leaves" in graph-theoretic terms) would need to be put on hold, and that it would not suffice for the first generation of children to be put on hold. Utterly counterintuitive and clunky.

[QUOTE=macula;83874]Thanks, Bill.

That putting a parent 'on hold' would make its children unavailable seemed to me so natural that I forgot the 'feature' that you mention: Indeed, the 'context' field for groups is merely a default context for new children.
[/quote]
Not sure I see what other function you would have it be...only in a subset of cases will all of the children have the identical context, and without that identical context, using the parent's context to decide availability makes little or no sense. Restricting action groups to be collections of actions with the same context would be needlessly restrictive, and for what gain in return?
[quote]
As for a usage scenario, quite straightforwardly, I wanted to defer an action group indefinitely to the future—i.e. to put it 'on hold' :-)
It only seemed natural to me to put the parent task 'on hold' rather than changing the context of each child.

Consider that some of the children may be action groups themselves. In such a case, "putting the children on hold" means that the lowest-level actions (the "leaves" in graph-theoretic terms) would need to be put on hold, and that it would not suffice for the first generation of children to be put on hold. Utterly counterintuitive and clunky.[/QUOTE]

Nah. Just put a (future) start date on the action group, and it behaves exactly as you would want. OF 2.0 will let you put the action group on hold, I believe, but until then, start dates work well.

Sample project with nested action group to be put on hold:
[URL=http://img18.imageshack.us/i/screenshot20100819at341.png/][IMG]http://img18.imageshack.us/img18/9274/screenshot20100819at341.png[/IMG][/URL]

Put on the start date to put nested action group on hold:
[URL=http://img294.imageshack.us/i/screenshot20100819at341.png/][IMG]http://img294.imageshack.us/img294/9274/screenshot20100819at341.png[/IMG][/URL]

Sample project, action group not yet on hold, context view, remaining actions:
[URL=http://img820.imageshack.us/i/screenshot20100819at343.png/][IMG]http://img820.imageshack.us/img820/865/screenshot20100819at343.png[/IMG][/URL]

Sample project, action group now on hold, available actions:
[URL=http://img96.imageshack.us/i/screenshot20100819at344.png/][IMG]http://img96.imageshack.us/img96/6118/screenshot20100819at344.png[/IMG][/URL]

Right, Bill. In fact, I've been doing this—using start dates as a substitute to putting groups on hold—for a long time.

Your point is well taken, but please note that I am arguing for inherited non-availability from parents to children, not for inherited contexts. The children would retain their individual contexts, which of course could be different from each other.

Conceptually, 'on hold' is quite different from having a future start date. Of course, one could use a dummy date, such as 1/1/2500, as a substitute to a genuine 'on hold' context. Not very elegant but functional. At any rate, I am looking forward to this refinement in OF 2.0.

Now, if only I could create a perspective showing only the projects 'on hold' AND the actions/action groups starting at a later date...

[QUOTE=macula;83863]At least in the latest OmniFocus beta version (v77.62 r137400, released 19 August), if the parent of an action group is given an unavailable "on hold" context, the children actions remain available.

Is this a feature or a bug?
[/QUOTE]

It's intended as a feature, but we're willing to consider to other opinions. :-)

The context field sets the context for that item. New items you create inherit their context from the parent, whether that parent is a project or another row.

Changing the context of a parent doesn't change the context of any existing children; only new ones you create. We could certainly consider that as a feature request if folks want it.

[QUOTE=macula;83874]Utterly counterintuitive and clunky.[/QUOTE]

I would respectfully submit that the previous behavior seemed equally counterintuitive and clunky to a large group of people. While you don't personally agree with this change, it does help that other group of customers.

I would also respectfully submit that putting an action group into an on-hold context didn't put the children on hold in 1.7.x, either. I know your preference is that we leave things the way they were in 1.7.x, but the change we're making in 1.8 is a red herring here. :-)

I'm not dismissing your concerns, of course! If you can help us find solutions to any problems the 1.8 workflow doesn't address, that will help everyone. We've gotten a lot of feedback over the years from folks that don't understand or like the way action groups were operating in previous versions; we can't ignore that.

That all said, does the start date solution Bill offered work sufficiently well for your purposes?

Reviewing the thread, I realize that one thing I failed to mention is that we've talked about was making "Waiting" and/or "On hold" [URL="http://forums.omnigroup.com/showpost.php?p=76260&postcount=27"]into an action state[/URL], rather than linking it to contexts the way it currently is.

I don't think that we can do that for 1.8 - it's a bigger change - but maybe that's the best overall solution?

[QUOTE=macula;83878]
Your point is well taken, but please note that I am arguing for inherited non-availability from parents to children, not for inherited contexts. The children would retain their individual contexts, which of course could be different from each other.[/QUOTE]
If the children retain their individual contexts, then what is the purpose of having a context for the parent? Only to be used as a baroque way to put the children on hold? I'd be interested to see the draft of your documentation of that behavior for new users :-) It doesn't seem like an evolutionary step toward the 2.0 object model to me.

Another way to put this group of actions on hold (that I personally prefer) without losing their context is to group them up and put an on-hold action sequentially in front of their group. With the future start date method, for me, I don't see immediately why those actions are on hold.