Security Cube

[kelso]

Hello guys,

I have a security question. I developed a security cube for version, year and month in order to prohibit users to submit or adjust data without admin permit.

This "writing security"cube is has the following dimensions:
- Month
- Year
- Version
- M (which has only the securityflag string)

I created a cell security cube of the accounting cube (9 dimensions) which has the following rule:

SKIPCHECK;

[]=S:IF(DB('writing_security',!year,!lmonth,!version,'SecurityFlag') @= 'WRITE','WRITE','READ');

I complete my matrix on the writing process cube and I apply security refresh and works great but:

First Question: On the writing security cube I was supposed to write a FEEDSTRINGS; and a feeder sentence or is ok to leave it like this?, SKIPCHECK should work for numbers consolidation, but here i am talking about letters, I dont understand why I have to feed and If I have to do it. (I saw that somebody put that Skipcheck so i decided to put it)

Reference Manual:

FEEDSTRINGS
Rule-generated string values are not displayed when a view is zero-suppressed unless the string resides in a cell that is fed.

Second Question: My data cube is empty, if it gets full or used in long views it is going to be slow because of the use of an extensive cell security?

Please help, thanks.

[kelso]

??

[kelso]

Unless you have a small cube you should always use Skipcheck. If you dont use it in a large cube it may bring down the server since number of feeder flags generated = n level elements in dim1 * n level elements in dim2 * etc can be more than grains of sand in the observable universe etc etc

Strangely though the cells in an element security cube do not have to be fed for the security to take effect. Mind you TM1 there are a lot of cases in TM1 where the feeders dont matter.

this was on http://forums.olapforums.com/posting.ph ... =3&p=14225

Just for my second question: "My data cube is empty, if it gets full or used in long views it is going to be slow because of the use of an extensive cell security?"

With my rule the "read" is used in very cell, this implies lots of memory on huge cubes?

[lotsaram]

Cell security should only be used rarely when security needs to be truly multi-dimensional. Usually cube level security and element level security will suffice.

If your cell security cube rule has "READ" in every cell then there is no need for it to exist and you should get rid of it as this is only placing overhead on the system for no benefit.

[kelso]

Thanks Lotsaram.

What I meant is that with that rule, every other cell that doesnt have a WRITE status is READ. The solution works great but Memory seems to be a concern. Even when I thought and test it, I felt is was too simple.

You meant that Cell Security, specially in this case when I want to let submission users to input by the year month and version indicated should not be used like this.

What can be a better option? That user control each dimension security for this three dimensions and each group? Maybe is a basic question for the forum, but I read some posts and I got confused. I guess is a common requirement.

Help...

[lotsaram]

Depending on how locked down you are planning on having your forecast UI you really don't need to resort to cell level security in order to control the "rolling" of the forecast period (or put another way the interaction between the versions available for data input and your time dimensions). I am guessing that what you want to do is to prohibit the retrospective adjustment of forecasts for periods that have either actualised or are within a timefence.

Unless the UI is very open (eg. users open cube views directly to enter forecasts ... not very common) you can achieve this result without ever needing to resort to cell security. Just use rules with time logic similar to your existing READ/WRITE cell security rule (or similar to a "rolling forecast" rule). All that is needed is to have a rule driven "rolling forecast submission" version wit rule logic of "IF(past month, actual, STET)" and expose this version in the submission templates. You can adjust this approach slightly by having an additional version(s) eg. "forecast submission" and "final forecast" and adding TI to the mix to take a final frozen version of the forecast (which is read only to all users with element security) at the last time when the time window was available for re-forecast. You can even set up variance reporting with an additional consolidation in the version dimension to automatically pick up on any sneaky users who do retrospectively change a forecast.

This is the generic approach I would usually recommend over cell security. Does this make sense?