Originally Posted by macula
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?
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: