Oops single typos and 2 resulting copy/paste errors now fixed. OK, for clarity, Name.contains() or similar will likely work, but for
legacy support reasons. Put another way, it's best no to start out learning syntax that may stop being supported - and I apologising for inadvertently contributing to the confusion.
Early in TB's existence, action code was much, much smaller in the scope of what it could do. You could write code like:
Color = bright redTB would guess you meant the attribute Color should be set to the string value 'bright red', by cutting up the expression, checking the bit left of the operator matches a currently defined attribute, etc. Easy for the user to just write what they mean … except with more complexity the method doesn't scale well. So now, we'd write:
$Color = "bright red"Now TB immediately knows we're setting the value of an attribute to a string value - it doesn't have to work out if the value is "red", "bright" or "bright red", it uses the provided quotes. However, there are plenty of users out there with old docs that don't want to update (nor know how to) so the old code is supported. That's why I list it as '
deprecated' in aTbRef. It may work, but it's not best practice to do so.
Also, as action code gets more complex, 'rules' make learning easier - you quickly spotted my earlier typo of omitting a $, using 'Name' not '$Name'.
So … it's complicated! But I hope that's helped give some background.
Meanwhile, with .contains() and .icontains() use the latter if you absolutely want a case-insensitive match and wend to override any lurking case-sensitivity switches.