TM1 Forum

Has anyone else ever seen a rule like this being automatically generated, or am I going mad?

[] = S:if( ~ !}GROUPS @= 'ADMIN', 'WRITE', STET);

J

What is

~ !

I have not seen that before.

Eric,

The !}GROUPS is just a reference to the }GROUPS dimension - basically allows the rule to apply to any }GROUPS element. The "~" is TM1's way of saying the logical operator "Not". Other logical operators are "&" for "And" and "%" for "Or". So, in this rule it's saying if the group is Admin, put in the text WRITE, otherwise leave it be and let users enter in whatever text they want.

John,

As to how this rule got there, I don't remember seeing it show up anywhere, but then I'm not sure where you're seeing it or where I should look - presumably a security cube somewhere? What version?

Regards,

Must have a had a brain fart. I am aware of the logical operators like the ~. When I first read the post I thought it was using 2 operators, the ~ and ! together ("~!) and my mind went Huh??? and didn't even register it was "~" and "!}GROUPS"

Probably not thinking because I am fustrated with SAP.

John, have you been down the pub instead of working or something?! I know it's a nice day but..

TM1 has never automatically created any rule ever, for anything. In some cases it'd be nice, but I've never seen it in anything up to 9.0. That rule is actually saying the opposite of what Mike has posted ;

[] = S:if( ~ !}GROUPS @= 'ADMIN', 'WRITE', STET);


[] = for all elements
S: = that are strings

If the current element in the }groups dim is NOT (~) equal to 'ADMIN', enter the value 'WRITE', otherwise do nothing.

If could just as easily be written as;

[] = S:if( !}GROUPS @<> 'ADMIN', 'WRITE', STET);

They do exactly the same and it's just up to the individual as to which method they use. I prefer the "positive discriminator" of @<> just because that's how I've read formulae since i was a kid ( if A does not equal B etc).

Yes it's a security cube.

J

Whoops. Sorry, the mind and fingers got crossed up - thanks for highlighting my mistake Steve.

John - which security cube? It sure seems like an odd rule to have been added automatically - is this TM1 9.1 or have you been foolishly working with the 9.4 beta?

Regards,

It was the element security for a data variables dimension.

I too think it's odd that TM1 might create an automatic rule, but then it's also odd that I have no recollection of writing it 2 and a half years ago!

I suppose I was wondering if this rule night have been a default of some sort, but when I think about it that would be illogical as the security cube only exists if you set up security to begin with.

The increasing frequency of these senior moments is a great cause for concern

Thanks all for the replies

J

Hi John,

I remember SPF Plus creating security rules. Could it be SPF Plus is/was running in your environment?

Michel

If something did create the rule, it's a pretty scary one.

Everyone gets Write access? Not really what you want when the rabid compliance auditors descend.

We have had issues with rules in control cubes under 9.1 SP3 - I think there was a thread about it in the 'other place'.

However it got there, wouldn't it be better changed from

[] = S:if( ~ !}GROUPS @= 'ADMIN', 'WRITE', STET);

to
[}GROUPS:'ADMIN'] = S:stet;
[] = S:'WRITE';

?
I do like to minimise IF tests as far as possible...

David Usherwood wrote:However it got there, wouldn't it be better changed from

[] = S:if( ~ !}GROUPS @= 'ADMIN', 'WRITE', STET);

to
[}GROUPS:'ADMIN'] = S:stet;
[] = S:'WRITE';

?
I do like to minimise IF tests as far as possible...

David,

Have you actually tried to save the rules as you've written them in a security cube?

If you do, you may find a reason why the original author chose to use some form of IF logic - the rules compiler (even in 9.1 SP3) chokes on the "}" in the dimension specifier. To be fair, you could remove "}GROUPS:" from that rule and it will save, as long as the name "ADMIN" isn't ambigous (which it would be in }ClientGroups for sure, and possibly in other security cubes depending on object names).

Anyway, sorry to throw a minor wrinkle in there - I've stumbled into this inability to refer specifically to the control ("}") dimensions in square bracket expressions several times before.

I definitely agree with you that it is preferable to break this kind of logic up as you've laid it out.

Regards,

Errr.....
No.
But when I did, I got the same behaviour you saw - it appears the rules parser can't handle squiggle dimension names in the [dim:'Element'] syntax. B***er.

And also, looking through our standard demo setup, which was touched by SPF many years ago, I see similar rules to those John H describes. In (eg) the }DimensionSecurity cube, I see:
['}CLIENTS']=S:IF(!}GROUPS@='ADMIN',STET,'WRITE');
['NOTIFY ADMIN']=S:IF(!}GROUPS@='ADMIN',STET,'ADMIN');
['}BEACHWARE']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}BEACHWARECLIENTS']=S:IF(!}GROUPS@='ADMIN',STET,'WRITE');
['}BEACHWARE_BATCH_REPORTS']=S:IF(!}GROUPS@='ADMIN',STET,'WRITE');
['}BEACHWARE_BATCH_REPORT_ITEMS']=S:IF(!}GROUPS@='ADMIN',STET,'WRITE');
['}BEACHWARE_MESSAGES']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}BEACHWARE_MESSAGE_DATES']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}BEACHWARE_TEXT']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPFADMINSECURITY']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPFCUBES']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPFFORMATPROPERTIES']=S:IF(!}GROUPS@='ADMIN',STET,'WRITE');
['}SPFMENUITEMS']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPFMETHODPROPERTIES']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPFMETHODS']=S:IF(!}GROUPS@='ADMIN',STET,IF(DB('}SPFADMINSECURITY',!}GROUPS,'VSPFNETHOME')@='-1','ADMIN','READ'));
['}SPFPROPERTIES']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPFREPORTS']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPFREPORTS2']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPFRULEPROPERTIES']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}SPF_WORKFLOWMESSAGES']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['NOTIFY ADMIN DATA']=S:IF(!}GROUPS@='ADMIN',STET,'ADMIN');
['SPF_WORKFLOWINFO']=S:IF(!}GROUPS@='ADMIN',STET,'WRITE');
['}CLIENTS']=S:IF(!}GROUPS@='ADMIN',STET,'WRITE');
['}ELEMENTATTRIBUTES_NOTIFY NAME']=S:IF(!}GROUPS@='ADMIN',STET,'WRITE');
['}ELEMENTATTRIBUTES_}SPFCUBES']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}ELEMENTATTRIBUTES_}SPFMENUITEMS']=S:IF(!}GROUPS@='ADMIN',STET,'READ');
['}ELEMENTATTRIBUTES_}SPFMENUITEMS']=S:IF(!}GROUPS@='ADMIN',STET,IF(DB('}SPFADMINSECURITY',!}GROUPS,'VSPFNETHOME')@='-1','ADMIN','READ'));
['}SPFMENUITEMS']=S:IF(!}GROUPS@='ADMIN',STET,IF(DB('}SPFADMINSECURITY',!}GROUPS,'VSPFNETHOME')@='-1','ADMIN','READ'));

And you can be darned tootin' sure that no-one in InfoCat would write rules all smashed together like that. Step forward, Dynamic Decisions! (Wonder how they are getting on these days?)

Well I have had SPF on various machines at various times so it's possible that this results from that but it would perhaps be unfair to blame them.

Anyway - I'm just glad that Keith Faulkner noticed this as I was really scratching my head here before he pointed out the rule!

Also just to be really anal about the if test in the security rules. You don't need it at all since you can't override the security permissions of the admin user group.

That said it would be interesting to understand how TM1 works once the rule is compiled...

Is there any difference between

['a'] =N:10;
['b']=N:20;
and
[]= If ( !dim1@='a', 10, 20);
(assuming only elements a and b in dim1...)

once the rule is compiled?