Alias doesn't work in rule right hand side

[michalb]

Hello,

I've been experiencing issues with aliases in rules right hand side area. Regardless of how bad the idea of having aliases in rules is, I'd like to understand why it stopped working (I saw this apporoach in multiple models and it worked). The fact aliases work in left hand side - area definition brackets, bothers me even more.

So I have simple cube "Cube" with 2 dimensions:
- "Dimension 1" - elements there: numerics under one consolidation. Dimension 1 has aliases - and they are different than original elements names.
- "Measures" - elements there: few strings, few numerics. Measures doesn't have aliases.

I wanted to write a rule for one of the elements of the "Dimension 1" called "999" with alias value "999 - Account". There are my attempts:

1.

[]=S: IF(!Dimension 1@='999', 'text', STET);

after that I had "text" on all my string measures as expected

2.

[]=S: IF(!Dimension 1@='999 - Account', 'text', STET);

after changing RHS of the rule to alias, rules stopped working

3.

['999']=S: 'text';

worked the same like first rule

3.

['999 - Account']=S: 'text';

worked the same like first and third rule

I checked it also on }CubeSecurity cube of that cube, where there's also dimension }Groups with aliases. Unfortunately the same issue no matter what dimension I write rules about. LHS works, RHS doesn't. I just feel like the answer to my question is quite easy, but as for now I have no idea what's happening.

[ascheevel]

The issue is how you're referring to the alias and I would say this is expected behavior. You're doing a string comparison, asking if !Dimension1 element-'999'- is equal to a specified string value - '999 - Account' will never evaluate to true as they are not the same. When referencing !<dimension> in the rules, you will always be getting the principal element name.

Sounds like you understand that you shouldn't be using aliases in rules and I won't lecture but it's worth saying, "don't, just don't do it".

[lotsaram]

What he said.

It doesn't matter if an area statement on the LHS uses an alias, when !dimension is used on the RHS it will always evaluate as the principal name. This is how it has always been and will always be.

At least you understand that using aliases on the LHS is a bad idea. Don't do this.

[michalb]

Thank you for clarifying that for me. I'm aware of consequences of using aliases in rules. Unfortunately the model I'm dealing with right now has them basically in every rule statement. Turned out aliases are used in functions, e.g. ElIsAnc('Dimension 1', 'Alias value', !Dimension 1) rather than in comparisions.

[ascheevel]

Turned out aliases are used in functions, e.g. ElIsAnc('Dimension 1', 'Alias value', !Dimension 1) rather than in comparisions.

and an alias works on the RHS in that situation because it's being used to refer to the element object. An element object is much more than it's string name and can be referenced by principal name or defined alias living up to it's definition. In Juliet's famous line, A rose by any other name would smell as sweet, the object with principal name rose will exist unchanged and still smelling sweet regardless of what name/alias is used to refer to it.