The Omni Group
These forums are now read-only. Please visit our new forums to participate in discussion. A new account will be required to post in the new forums. For more info on the switch, see this post. Thank you!

Go Back   The Omni Group Forums > OmniFocus > OmniFocus 1 for Mac
FAQ Members List Calendar Search Today's Posts Mark Forums Read

 
BUG or FEATURE in latest 1.8 sneaky peek? Thread Tools Search this Thread Display Modes
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:
Originally Posted by macula View Post
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.
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.
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:


Put on the start date to put nested action group on hold:


Sample project, action group not yet on hold, context view, remaining actions:


Sample project, action group now on hold, available actions:
 
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...

Last edited by macula; 2010-08-19 at 03:29 PM..
 
Quote:
Originally Posted by macula View Post
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?
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:
Originally Posted by macula View Post
Utterly counterintuitive and clunky.
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" into an action state, 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?

Last edited by Brian; 2010-08-19 at 04:17 PM.. Reason: add link to ken's post
 
Quote:
Originally Posted by macula View Post
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.
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.
 
 


Thread Tools Search this Thread
Search this Thread:

Advanced Search
Display Modes


Similar Threads
Thread Thread Starter Forum Replies Last Post
New sneaky peek dougtoft OmniWeb General 1 2010-03-15 09:21 AM
I want a new Sneaky Peek! sfkeydel OmniFocus 1 for Mac 3 2009-01-16 03:56 PM
New built in perspectives in latest sneaky peek ext555 OmniFocus 1 for Mac 11 2008-10-13 05:36 AM
security hole in latest Sneaky Peek (7/20) swhobbit OmniFocus Syncing 2 2008-07-21 06:24 AM
Help - lost access to data with latest sneaky peek kocab OmniFocus 1 for Mac 1 2008-07-16 07:01 AM


All times are GMT -8. The time now is 11:39 AM.


Powered by vBulletin® Version 3.8.7
Copyright ©2000 - 2019, vBulletin Solutions, Inc.