TM1 Forum

In Forecast Dimesnion, we have 4 Elements LY, Actual, Forecast and Plan. Security has been setup in
Forecast Dimension as :
LY = Read
Actual = Read
Forecast = Write
Plan = Locked.
But still LY and Actual is On in Views during users entering data in Forecast cell . Cell Status are showing Editable .
Can any one help to how can I locked LY and Actual cell during forecast data entry. Am i missing any security setup?
Thanks advance for all.

You mentioned "users", but just thought I'd mention that security doesn't apply to admins.

A more likely thing is that security is additive. If a user is in another group that does have access to the element then they will get write access.

If that doesn't help, can you provide the rule you're using in the cell security cube, plus a screenshot of the cube and its dimension structure?

Martin

Yes, need more info. Snapshot is better.

It seems you only setting " Element secutiry", not "Cell security".

Cell Security Control the permission of "Cube Cell" to each user( which cell they can read, write ).

Element Security Control the permission of "This element" in the dimension to each user( which element they can read, or change it's attribute ).

In you Case,
LY = Read
Actual = Read
Forecast = Write
Plan = Locked.

"LY" is read in element security means " user only can see this element, but cant change it", not the cell in cube.
So that, of course, this user can write to the cell within element "LY".

You have to set cell security.

I organzied the cell security overwite rule from offical documentation.

Dim(N) > Cube(N) > Element(N) > Cell(N,R ) > Cube(R) > Cell(W) > Element(W,R) > Cube(W) >Dim(R,W)

in your case , Cell(W) and Element(R) ( Cell(W) > Element(R) )
final result is Write.

hope it's helpful.

solverxyz wrote:It seems you only setting " Element secutiry", not "Cell security".

Cell Security Control the permission of "Cube Cell" to each user( which cell they can read, write ).

Element Security Control the permission of "This element" in the dimension to each user( which element they can read, or change it's attribute ).

In you Case,
LY = Read
Actual = Read
Forecast = Write
Plan = Locked.

"LY" is read in element security means " user only can see this element, but cant change it", not the cell in cube.
So that, of course, this user can write to the cell within element "LY".

You have to set cell security.

I organzied the cell security overwite rule from offical documentation.

Dim(N) > Cube(N) > Element(N) > Cell(N,R ) > Cube(R) > Cell(W) > Element(W,R) > Cube(W) >Dim(R,W)

in your case , Cell(W) and Element(R) ( Cell(W) > Element(R) )
final result is Write.

hope it's helpful.

I think you are right that the OP is meaning element security not cell security. However your advice about what element security does and needing cell security is 100% dead wrong.

Element security of READ does restrict ability to write data to all cubes with the dimension, and if applied correctly should be all that the OP needs. Maybe you are getting confused with dimension security? In any case might be good to brush up in the manuals.

I think you are right that the OP is meaning element security not cell security. However your advice about what element security does and needing cell security is 100% dead wrong.

Element security of READ does restrict ability to write data to all cubes with the dimension, and if applied correctly should be all that the OP needs. Maybe you are getting confused with dimension security? In any case might be good to brush up in the manuals.

Sorry for misguiding.
I mean the overwritten rule of the "cell security ".

By default, when you applied a Cube as a Write security, all cells are write except the cells within the elements which's security are set to "None".
Sometimes, the Dimension is shared by the several cubes. In that case, to set cell security is necessary.

Back to the orginal post, and yes, you can control the cell security by setting elements's access to "None" if it's parent dimension is not shared.

The rule I organized is use for judging the final result of a cell security if the security of the Cube, Dimension, Element, and cells ( or, at least 2 of them ) are all applied.
Dim(N) > Cube(N) > Element(N) > Cell(N,R ) > Cube(R) > Cell(W) > Element(W,R) > Cube(W) >Dim(R,W)


Example1 .
you set a cube as read, the dimension as write, the element is write.
Cube(R) > Element(W,R) >Dim(R,W)
The cell is Read in the cube ( Cube(R) ).

Example2 .
you set a cube as write, the dimension as read, the element is read.
Cell(W) > Element(W,R) > Cube(W) >Dim(R,W) ( because no cells security is set, it's write by default)
The cell is "write" in the cube. ( Cell(W) )

I just test that in my local server.

There's a fair bit of misinformation gathing up in the last couple of replies so for clarity incase anyone stumbles across this thread in the future, thought it would be worth clearing up.

Ignoring element security cubes for now, assuming you are in a single non admin security group then the simplest way of understanding security as far as I am concerned is in laymans terms as follows -

If the cube is set to READ in }CubeSecurity, you can only read from it regardless of later security settings. This is the first gateway to being able to write to a cell - hit READ at this stage and you can forget about writing anything to the cube.

Dimension security is largely useless for most instances with the exception that if the user doesn't have at least READ access then they won't be able to see the thing in the first place causing cube viewer to throw an error message when opened. For the vast majority of cases from a user perspective, just leave this on WRITE and forget about it in my opinion.

Element Security held in the }ElementSecurity_dimname can be used to restrict access to individual elements. NONE means they literally can't see them so obviously they can't write to it. READ means that a user can see information on the element but not write to it. WRITE means the user can load data to that element assuming they have WRITE access to all other elements referenced in the data point.

What this means is that if a user is looking at a 3 dim cube and was trying to change March / 2013 / Sales then they would need WRITE access to the cube in }CubeSecurity in the first place, WRITE access to March in the }ElementSecurity_Month dim, WRITE access to 2013 in }ElementSecurity_Year and WRITE access to Sales in }ElementSecurity_Variable cube.

Now for reasons unknown to mankind, the security group that the user is in changes the access to Sales to be READ in the }ElementSecurity_Variable cube. Now the user cannot write to the data point as he is unable to write to "Sales" anywhere in the model regardless of the other security settings.

The point raised back at the start of the thread by Martin which is very likely to be the OP's problem is that security is additive. Therefore if the user is added to a different security group which randomly had WRITE access to "Sales" and nothing else then the user could now write to the data point again because they have access to the data point due to the addition of the security settings between the two groups - they now have access to write to Sales from Group B and access to the other data points from Group A.

If a user has access to more than one group and the same element / cube is referenced in security then the highest level of access will be applied. ie, if Group A provides NONE and Group B provides WRITE then Group A's security is effectively ignored as Group B's security is higher level of access and is therefore used.

Also worth pointing out that when a dim is created, all elements are automatically set as WRITE for everyone until the point that you change security on a singular element. At this point the }ElementSecurity_DimName cube is created in the system and from that point onwards any new elements added to the dim will default to having NONE security for all user groups. Makes sense if you think about it.

A common way of trying to automate some of the security burden is to then place rules in the }ElementSecurity_DimName cube which does an ELISANC check against key consolidations in the dim and applies blanket security to certain groups for anything below it. eg, If an element is an ELISANC of "Sales" then allow WRITE access to the "Sales" security group, etc. Quick search on the forum will turn up numerous examples of this I'm sure.

Obviously admin users have full access and bypass security. Solverxyz's answer in the last post is likely to be showing write access in his testing because they are an admin on their server.

Cell level security is a further layer of security used in specific cases - usually when trying to restrict actuals / forecast info when a dimension is shared between multiple cubes. These are key parts of development but I'd suggest looking through the documentation / reading up if you have to do this as there are pros and cons to using this approach. For the purpose of this thread, I'd be very surprised if the OP had to dabble in this, I think Martin probably nailed it in the first reply and that additive security can be used to solve the problem in the first place.

Just a few points of clarification regarding security:

1) TM1 stores all it's security data in cubes. Cube security is in }CubeSecurity, Dimension security in }DimensionSecurity, Element security in }ElementSecurity_NameofDim and Cell security in CellSecurity_NameOfCube.

2) No security exists, by default, when you establish an instance of TM1. This means no one but Admins can see or do anything. At a minimum you must establish cube security.

3) Once you establish cube security, by default, all other security tranches match the cube they are associated with. This means that if you have WRITE to a cube, you have WRITE to the entire cube, meaning all the intersections.

4) In the instance where you have contradictions in security, rights always default to the lowest common setting. What I mean by this is that if you give WRITE to a cube, but READ to all the dimensions in the cube, then your access is to that cube is going to be READ. The same holds true for element security.

5) Security is additive. You get the HIGHEST level of security assigned based on the combination of all the groups you are in. If you have READ based on membership in Group_1, and WRITE based on membership in Group_2, your access is WRITE.

6) Rules are a great way to do security. However, please be aware that should events happen that change how a security-based rule populates the cube, meaning an attribute is assigned, or some other event happens, you must MANUALLY refresh security (either through the interface or via a TI process command to make that change actually be reflected in a user's security.

Obviously admin users have full access and bypass security. Solverxyz's answer in the last post is likely to be showing write access in his testing because they are an admin on their server.

I am pretty sure that I am using a non-admin client. I created a new client and group, and set the security to the cube, dimenson, and element.
After I login the server, only one 1 cube and 4 dimensions could be saw.


What I posted before was correct.

you set a cube as write, the dimension as read, the element is read.
Cell(W) > Element(W,R) > Cube(W) >Dim(R,W) ( because no cells security is set, it's write by default)

The cell is "write" in the cube. ( Cell(W) )

I just checked again.

Considering a cell that has been saw by a client, the only way to make a special cell "READ" is to set Security of Cell as "READ", or the Cube as "READ".

In additional, I agree that the best way to control "cell security" is to make a adequate rule of }CellSecurity_CubeName.

That means you can make a security-switch cube for Power users to avoid the normal users change any data in the specified slice of the cube after the day for closing account.

solverxyz wrote: What I posted before was correct.

you set a cube as write, the dimension as read, the element is read.
Cell(W) > Element(W,R) > Cube(W) >Dim(R,W) ( because no cells security is set, it's write by default)

The cell is "write" in the cube. ( Cell(W) )

I just checked again.

Considering a cell that has been saw by a client, the only way to make a special cell "READ" is to set Security of Cell as "READ", or the Cube as "READ".

No, this is not correct. It is a very long way from correct. Usually it would be a good idea to listen to people with a collective 40+ years experience with TM1, but it seems you know best. I won't waste my breath or typing to try and explain again how TM1 security works, but maybe someone else will take up the challenge.

lotsaram wrote:

solverxyz wrote: What I posted before was correct.

you set a cube as write, the dimension as read, the element is read.
Cell(W) > Element(W,R) > Cube(W) >Dim(R,W) ( because no cells security is set, it's write by default)

The cell is "write" in the cube. ( Cell(W) )

I just checked again.

Considering a cell that has been saw by a client, the only way to make a special cell "READ" is to set Security of Cell as "READ", or the Cube as "READ".

No, this is not correct. It is a very long way from correct. Usually it would be a good idea to listen to people with a collective 40+ years experience with TM1, but it seems you know best. I won't waste my breath or typing to try and explain again how TM1 security works, but maybe someone else will take up the challenge.

Wow, my admiration Lotsa. That was remarkably restrained. Indeed, gold-medal diplomatically restrained. The one that I was typing was less so, but I'll still make one point from my now discarded reply, and one which is more for the benefit of any other new users who might stumble across this thread and be brain-achingly confused by it.

SolverXYZ, I am prepared to accept that your intention is to help the original poster and that your motivations are good. But posting information which is at best misleading, and at worst completely incorrect... that does not help. At all. Quite the contrary in fact. Continuing to insist that you are correct when both Garry and Tomok have gone to some pains to point out why the information is incorrect helps even less. It hinders. It hinders greatly, and can cost new users quite some hours in understanding what they need to do to secure a TM1 model and why. I was, originally, going to point out what the problems in your latest post are but I'll stick to only a couple.

Cell(W) > Element(W,R) > Cube(W) >Dim(R,W)

I don't know what these "diagrams" mean in your own mind, but to everyone else they mean nothing at all. The objects aren't even in the right hierarchical order. And the distinction between "(W,R)" and "(R,W)" for instance is, to put it as politely as possible, "obscure". (As is their intended meaning.)

Dim(R,W) ( because no cells security is set, it's write by default)

Please re-read the parts of this thread which describe the difference between cell security, and element security. Unfortunately the Humpty Dumpty approach (that is, "When I use a word, it means just what I choose it to mean - neither more nor less") tends to create problems when describing the functioning of computer applications (or any other technical subject) to others.

I'm not trying to discourage you from posting in the future but if you're posting things which more than one MVP is telling you are wrong, it's usually time to step back a bit and listen.

I applogized what I replied before.

After I tried serval hours, turns out it's was my misunderstanding about the cell security.

Yes, in normal case, the cell security can be controlled by the }ElementSecurity_%DimensionName%.

Sorry for wasting your time on me. But also thanks for help me getting more understanding the cell security.

It is same if you go to Dim-> Security -> Elements Security Assignments