TM1 Forum

Hi all,

If I build the }CellSecurity_cube1 for the cube1, the }ElementSecurity_dim1, }ElementSecurity_dim2 and etc don't work anymore. Is it correct?
For example dim1 is year dimension, dim2 is datatype dimension. For "2016" in dim1, "d1" in dim2, if }CellSecurity_cube1 sets the cells for "2016" "d1" as WRITE, even }ElementSecurity_dim1 sets "2016" as READ, and }ElementSecurity_dim2 sets "d1" as READ, the the cells in cube1 for "2016" "d1" are still writable. Vice versa.

CellSecurity takes over the controll from ElementSecurity. Since there are more ElementSecurity, it will be a lot of work to build CellSecurity to cover the authority concepts.

Best regards,

Learn_TM1

Did you look at below post:
http://www.tm1forum.com/viewtopic.php?f=3&t=12623 Thanks

Is it possible to write one rule in }CellSecurity_cube1, which takes the security setting from the }ElementSecurity_dim? Could some one give me one example how to write it? Many thanks.

I tried to add the following rules to }CellSecurity_cube1:
[] = S:IF(DB('}ElementSecurity_dim1,!Version,!Groups')@='READ'
% DB('}ElementSecurity_dim1,!Version,!Groups')@='', 'READ','WRITE');

But it doesn't work. The }CellSecurity_cube1 doesn't take the "READ" "WRITE" from }ElementSecurity_dim1. Could some one help me out?

Learn_TM1 wrote:Is it possible to write one rule in }CellSecurity_cube1, which takes the security setting from the }ElementSecurity_dim? Could some one give me one example how to write it? Many thanks.

I tried to add the following rules to }CellSecurity_cube1:
[] = S:IF(DB('}ElementSecurity_dim1,!Version,!Groups')@='READ'
% DB('}ElementSecurity_dim1,!Version,!Groups')@='', 'READ','WRITE');

But it doesn't work. The }CellSecurity_cube1 doesn't take the "READ" "WRITE" from }ElementSecurity_dim1. Could some one help me out?

This approach should work if you apply it properly.
For example, you don't seem to understand the single quotes.

Hi Wim,

The problem has been solved. It really needs to consider the comprehensive conditions for the rules of CellSecurity cube, in order to take over the authentication of ElementSecurity and also fulfill the specified requirement of CellSecurity.

The rule in my last post uses the empty single quotes, because I want to cover the condition, when the ElementSecurity sets neither READ nor WRITE, but Empty. But this logic doesn't work anyway. So I changed it.

Best regards,

Learn_TM1

Learn_TM1 wrote:HThe rule in my last post uses the empty single quotes, because I want to cover the condition, when the ElementSecurity sets neither READ nor WRITE, but Empty. But this logic doesn't work anyway. So I changed it.

In fact, I meant this:
IF(DB('}ElementSecurity_dim1,!Version,!Groups')

The second single quote should be placed after dim1.

Wim Gielis wrote:

Learn_TM1 wrote:HThe rule in my last post uses the empty single quotes, because I want to cover the condition, when the ElementSecurity sets neither READ nor WRITE, but Empty. But this logic doesn't work anyway. So I changed it.

In fact, I meant this:
IF(DB('}ElementSecurity_dim1,!Version,!Groups')

The second single quote should be placed after dim1.

You are right. The cube name should be included in single quote. I changed it after that.

Could some one give me the official IBM document about the work mechanism of CellSecurity? It seems that the CellSecurity works different as DimensionSecurity and ElementSecurity. For the DimensionSecurity, it sets all Dimension to all user groups to WRITE. Then different ElementSecurity can block the specified element for some user groups, by setting it as READ. As long as ElementSecurity sets as READ, even DimensionSecurity sets as WRITE, the user group still can't change the value of those cells.

But CellSecurity is different. If CellSecurity sets for the specified Element as WRITE, even ElementSecurity sets it as READ, user can still change the value of the cell.

Could some one explain me why it is so? Is there document to describe it in details?

Learn_TM1 wrote:But CellSecurity is different. If CellSecurity sets for the specified Element as WRITE, even ElementSecurity sets it as READ, user can still change the value of the cell.

Could some one explain me why it is so? Is there document to describe it in details?

The TM1 Developer Guide has a section chapter Controlling Access to TM1 Objects > Interaction of Different Object Security Rights. It says the following:

If you apply different security rights to the objects that identify a cell of data, TM1 applies the most restrictive security right to the cell.

Which is not untrue, but it is not entirely accurate either, because it does not take into account Cell Security. Cell Security takes a sort of priority over other types of object security and allows you to override more restrictive access given by element or cube security. It is not a 100% override, because if e.g. your element security is set to NONE and cell security to WRITE then you won't be able to write to the cell because you will not see the appropriate element.

In summary, what you are observing is expected, even if not extensively documented. Cell security is just a different type of beast from other types of object security.

your element security is set to NONE and cell security to WRITE then you won't be able to write to the cell because you will not see the appropriate element.

Does this mean however that by using perspectives and knowing the name of the element then you could write to the cell because you have cell access despite not having element access?

qml wrote: Cell Security takes a sort of priority over other types of object security and allows you to override more restrictive access given by element or cube security.

Minor correction: I don't believe cell security can override cube security. So if cube security is READ and cell security is WRITE, the resolved security is READ.

In regard to the OP, why write a rule to make cell security read and replicate element security? A blank value for cell security allows element security to still be used. It only acts as an override in the specific cells that it has a value for. (This is assuming you have CELLSECURITYDEFAULTVALUE set to an empty value.)