First, do you really want to assign the rule? A simpler solution might be to have the parent have an attribute $SuggentedProjectName, which might default to be the same as $Name but could be changed for some containers.  

Note that an OnAdd action is a suggestion which you can override, while doing the equivalent action in a task is a constraint; if you try to override it. The agent will override you!

Mark B, Mark A -- thanks very much to you both. I see how to deal with the specific issue, and your advice is also very useful in larger knowledge of the program.

A follow-up on this:
Quote:


As a matter of elegance and/or efficiency in programming, is there a difference between the $Name(grandparent)=="Travel Projects" test, and the descendedFrom("Travel Projects") test? Is one cleaner than the other, less drag on the system, etc? Or, as is often the case in TB, are they just different routes to a common destination?

I can see how "grandparent" might be quicker, in that it's looking back a finite number of generations rather than the whole "descendedFrom" tree. But I can also see how, for that very reason, "descendedFrom" could be useful in covering further generations of sub-containers you might add. Just asking for fuller understanding of what I'm doing. Thanks!

Update  Mark A points out, "Edge case: if you move tasks, you may need to manually triage the $ProjectName values."
Yes, this has come up, and I've dealt with it by creating a stamp I can use for quick-and-easy setting of $ProjectName to the desired values.

The $Name test only grandchildren - which is the tasks only  - and thus needs only one query term. A descendedFrom() tests children, grandchildren and so on down, plus you need the extra prototype value test as well to make the if()'s query work.

I very much doubt there's a significant performance difference in your TBX. I was just trying to keep things short given the narrow scope of the layout allowed for it. I wasn't suggesting your original solution was sub-optimal (though perhaps I should have made that latter fact plain!).

Also, if tasks can be nested, or if some children of projects aren't tasks, then you would would need to use the descendedFrom() approach to correctly find all tasks.