rules on securities

[stingo]

Hi All,

I have a doubt.

I'm trying to create a rule on securities to close the years that are not useful in term of budgeting.

I put this rules on security cube for the year dimension:


SKIPCHECK;

FEEDSTRINGS;

[] = S:
IF((!}Groups @<>'ADMIN' % !}Groups @<>'DataAdmin' % !}Groups @<> 'SecurityAdmin'),STET, CONTINUE);
[] = S:
IF (( ATTRS('com_year',!com_year,'working_year')@='1'% ATTRS('com_year',!com_year,'budget_year')@='1'),'WRITE','READ');

FEEDERS;

where: budget_year and working_year are attributes on the year taking 1 just for the next and the current year.

I applied the rule and it seems to work (looking at the cellsecurity support cube) but logging with a non admin user I still can write on years without the attribute set.

Am I putting something wrong there?

Things I tried:

skip the case on admins
put everything in the same line
removing/putting the feedstring
creating separate rules for the 2 attributes
forcing the admin groups to 'ADMIN'

is there something I miss?
Once I did it on a different dimension and it worked fine.


do someone have an idea?

P.S. the year is not declared as time dimension in any cube.



Edit: Typos.

[qml]

3 notes:

a) Rule-based security settings will only kick in after you've refreshed security (either from the context menu or using a TI command).

b) You do not need skipcheck and feeders in this cube (unless, of course, you plan to use zero-supressed views with it).

c) Your cube performance would be better if you could avoid cell-level security. You should try looking at a combination of element-level security and cube-level security instead, if possible.

[lotsaram]

I put this rules on security cube for the year dimension: ....

... c) Your cube performance would be better if you could avoid cell-level security. You should try looking at a combination of element-level security and cube-level security instead, if possible.

Agree with you wholeheartedly except that from reading stingo's post I think it is clear stingo is talking about element security not cell security - in which case you are 100% correct. If using rules to generate element security then a security refresh is needed to update the security model as a rule save is not sufficient (and SkipCheck is not needed in a 2D cube).

A note from my observation. Security refresh is only needed for element security; if using rule driven cell security a security refresh does not seem to be needed for changes to take effect as the security settings seem to be evaluated on the fly when a user refreshes a view or otherwise attempts to read or write.

[qml]

I think it is clear stingo is talking about element security not cell security

Agree, guilty of not reading carefully enough.

[rmackenzie]

[] = S:
IF((!}Groups @<>'ADMIN' % !}Groups @<>'DataAdmin' % !}Groups @<> 'SecurityAdmin'),STET, CONTINUE);
[] = S:
IF (( ATTRS('com_year',!com_year,'working_year')@='1'% ATTRS('com_year',!com_year,'budget_year')@='1'),'WRITE','READ');
...
Am I putting something wrong there?

The first rule is saying for a non-admin group, STET all cells - meaning the second rule won't apply (and thus it is ambiguous what happens here as the cell is writeable by manual input and TI, etc). You should either swap STET and CONTINUE or use this line (note usage of equality, not inequality):

Code: Select all

[] = S: IF((!}Groups @='ADMIN' % !}Groups @= 'DataAdmin' % !}Groups @= 'SecurityAdmin'),STET, CONTINUE);

The second rule looks fine - you only want to allow WRITE access to years where the 'working_year' or 'budget_year' attribute is 1.

Personally I would write it as below. Your OR logic is faulty in the the first IF condition in another way because it will STET for any group.

Code: Select all

['}Groups':{'Admin','DataAdmin','SecurityAdmin'}] = S: 'ADMIN';
[] = S: IF (( ATTRS('com_year',!com_year,'working_year')@='1'% ATTRS('com_year',!com_year,'budget_year')@='1'),'WRITE','READ');

Actually, I think TM1 just ignores permissions like READ and WRITE on the Admin account and just assumes ADMIN.

[rmackenzie]

PS...

If your rule uses a FEEDSTRINGS statement, the SKIPCHECK statement should be the second statement in your rule. If your rule does not use a FEEDSTRINGS statement, the SKIPCHECK statement should be the first statement in your rule.

[csjean]

[] = S:
IF((!}Groups @<>'ADMIN' % !}Groups @<>'DataAdmin' % !}Groups @<> 'SecurityAdmin'),STET, CONTINUE);

I would also add that if you want to use the @<>, you should use the AND instead of OR.

I believe that this is one of your problems. The way I read it now is:

IF your group is different that ADMIN or different than DataAdmin or different that SecurityAdmin

This means that this rule will allways have a Hit. Because even if you have the ADMIN group, it is still diffeent than DataAdmin or SecurityAdmin.

You should defenitely go with the @= rule.

Cheers.

[David Usherwood]

If you don't have (and you probably won't have) any groups with Admin in their name, what about

Code: Select all

[] = S:
IF((scan('ADMIN',!}Groups) >0,STET, CONTINUE);

?

[paulsimon]

Actually, I think TM1 just ignores permissions like READ and WRITE on the Admin account and just assumes ADMIN.

That's right - the first rule is unnecessary.

I would disagree with one thing that someone said earlier though. I believe that the skipcheck is necessary but the feedstrings isn't.

Regards

Paul Simon

[tomok]

I would disagree with one thing that someone said earlier though. I believe that the skipcheck is necessary but the feedstrings isn't.

Why do you think you need skipcheck? All it does is force TM1 to turn back on the sparse consolidation algorithm when it has been turned off due to the presence of rules. All leaving it off will do is potentially slow down performance when looking at a view in the security cube itself.

[lotsaram]

I would disagree with one thing that someone said earlier though. I believe that the skipcheck is necessary but the feedstrings isn't.

Paul - we're talking about rules in security cubes here. I would be surprised if you use SkipCheck in your own security cube rules (if you do why do you?)
1/ Security cubes are 2 dimensional so almost by definition sparsity is not an issue and SkipCheck will not have any appreciable impact on performance
2/ In security cubes there is no consolidation (hence no reason for SkipCheck) as the only thing that matters is the single point intersection with the group which is always looked up directly
3/ in addition to point 2 security cubes are string cubes so there is no consolidation as string values apply and can be entered at any level
4/ Say you did use SkipCheck, then where would you feed from? For proper evaluation of rule security to apply the security model FeedStrings and Feeders are only needed when using ViewConsolidationOptimization

I stand by the point that SkipCheck and Feeders are not relevant for security cube rules. Of course there may be some very specific cases where this might not be true but I'm happy with the generalization.

[rmackenzie]

Hi Lotsaram - generally, I tend to agree with your generalization that Skipcheck and Feeders are not relevant for security cube rules. However, the exception might be when you want to be able to zero-suppress views on security cubes... not particularly common but not totally out of the ball-park either.

[lotsaram]

I have all but given up on getting zero suppression to work in views with rule derived string values. It just doesn't seem to work (I think this has come up in a few threads lately). Do you have a magic cure for getting FeedStrings to function as it should?

[qml]

For me the only good reason to use skipcheck and feders in security cubes is if you use the PrivilegeGenerationOptimization option in tm1s.cfg.
Using zero-suppressed views on security cubes is not convincing enough a reason for me, but I guess it's largely a matter of individual taste.

[lotsaram]

For me the only good reason to use skipcheck and feders in security cubes is if you use the PrivilegeGenerationOptimization option in tm1s.cfg.
Using zero-suppressed views on security cubes is not convincing enough a reason for me, but I guess it's largely a matter of individual taste.

Cheers. That's the config parameter I meant to refer to in case anyone was confused or mislead.

[rmackenzie]

Using zero-suppressed views on security cubes is not convincing enough a reason for me, but I guess it's largely a matter of individual taste.

Sure, in practice, this really isn't going to happen much.

Do you have a magic cure for getting FeedStrings to function as it should?

The question arising for feeding security rules would be one of exactly where to feed from. Essentially you are populating the cube with constant values (READ, WRITE etc) - there are no source cells so feeding is not going to be straightforward.

I recently had to produce flat files from zero suppressed cube views containing rule-derived string data. To feed those cells I used a string value in a system parameter cube as a constant input value and fed the rule-derived strings from that (irrespective of how the string value was calculated). Once I did that, FEEDSTRINGS just worked and the string values appeared in the file. Due to the low volume of calculations, I don't think there is much of a concern from a performance point of view but I guess it isn't the prettiest work-around.

I can't recall the last time I had to use this feature in anger! If my model relied heavily on rule calculated strings I would take a close look at the reason why.

[stingo]

hi all,

just to put a little clear things.

the feeders are there just for a try (it had not worked without so I figured it out what was happening with that).
I refreshed more than once.
The initial rule was in just one line so it was something like if no admin then write else admin and still was not working.

After a bunch of tentatives, I just put a TI and everything worked.

I'm still puzzled in why the rules were not working in the correct way.

[qml]

Did you refresh security or not?