TM1 Forum

Hi,

As per documentation the most restrictive security that applies to a cell is that which is applied.

For the same dimension element if a user is a member of two groups, one that gives read access and one that gives write access then the user ends up with write access. This is wrong as per the documentation.

I just want to double check the cfg, I seem to remember there is one that reverses the most restrictive rule. I can not find any trace of it though. Does it still exist? Can anyone remind me of it incase it is being applied by default?

TM1 Version is 2.0.7

Steve Rowe wrote: ↑Fri Dec 18, 2020 11:58 am For the same dimension element if a user is a member of two groups, one that gives read access and one that gives write access then the user ends up with write access.

This is the way it has always been for as long as I have been using TM1. I actually had no idea the documentation said otherwise. Not surprising since I haven't looked at the manuals in probably ten years or so.

Maybe the documentation is referring to the rule that says if you have WRITE to the cube, WRITE to the dimension, but READ to the element then you have READ. You have to have WRITE all the way down to have WRITE.

Thanks Tom, I had the feeling that I was off somewhere, the documentation doesn't really cover when the security model applies differently to the same object.

Not sure of the logic of implementing the security priority in different directions depending on the context.

Anyway this was quicker than reaising a support request, thanks!

Cheers,

tomok wrote: ↑Fri Dec 18, 2020 12:02 pmMaybe the documentation is referring to the rule that says if you have WRITE to the cube, WRITE to the dimension, but READ to the element then you have READ. You have to have WRITE all the way down to have WRITE.

That would be new to me. READ access to a dimension is sufficient for WRITE access to the cell, when WRITE is given at CUBE and ELEMENT level.

There is a flag CELLSECURITYMOSTRESTRICTIVE in }CubeSecurityProperties.

When CELLSECURITYMOSTRESTRICTIVE is yes, Element and Cell Security behave such that the most restrictive applies. For instance, if Element Security for a specific element is set to READ for a given Group and Cell Security for a cell referencing that dimension element is set to WRITE, then security will resolve to READ. If the CELLSECURITYMOSTRESTRICTIVE parameter is set to any value other than YES, then the server behaves as it did in the prior releases.

https://www.ibm.com/support/knowledgece ... ights.html

Is it what you are after? It is still there an works fine as expected.

Thanks macsir, no wonder I couldn't find the switch, looking in the wrong place!

Cheers