Order of priority for Security cubes.

[jbcraigs]

I need to know what is the order of priority among the Security cubes.

For example, if a user 'A' has 'Read' rights to an element of a dimension in ElementSecurity cube but write permissions within the CellSecurity cube, then would he be able to just READ or WRITE? And what happens if the rights are also specified in CubeSecurity and Dimension Security cube too?

Someone told me that the most restrictive right would take priority irrespective of where it is specified. I can't test it out since I don't have a dummy ID yet.

Thanks.

[Michel Zijlema]

I need to know what is the order of priority among the Security cubes.

For example, if a user 'A' has 'Read' rights to an element of a dimension in ElementSecurity cube but write permissions within the CellSecurity cube, then would he be able to just READ or WRITE? And what happens if the rights are also specified in CubeSecurity and Dimension Security cube too?

Someone told me that the most restrictive right would take priority irrespective of where it is specified. I can't test it out since I don't have a dummy ID yet.

Thanks.

The general rule is that most restrictive right will take priority (so if you give read rights to a cube it is not possible to grant write rights using dimension element security)... but Cell Security will override the other cube data security settings (so if you give read access to a cube you can override this to write access using cell security).
Please note that if you give none rights to a certain element using dimension element security, it is not possible to override this using cell security - the cell security will only be applied to the 'available' elements.

Michel

[jim wood]

Just a side point. The default (unless over written) is write so it's not worth stating write unless you are putting a catch all.

[Mike Cowie]

Please note that if you give none rights to a certain element using dimension element security, it is not possible to override this using cell security - the cell security will only be applied to the 'available' elements.

Hi Michel:

Actually, this is not totally true. The following scenario does work (let's say for a group called "Group A" browsing a "GL" cube):
* Give "Group A" at least READ access to the "GL" cube (this is important - you can't override this with Cell security)
* Give "Group A" NONE access to all elements in the Entity dimension used in the "GL" cube
* Give "Group A" at least READ access to all Entities for specific GL accounts in the "GL" cube, using Cell Security

"Group A" will actually be able to read this specified data in the "GL" cube.

Here's the big problem with this, and this is the issue you're referring to: none of the TM1 cube browsing tools (including Active Forms) are capable of handling this. Users in "Group A" won't be able to use something like the Cube Viewer to see any of this data that you've opened up via Cell Security because the cube browsers see that there's NONE access to Entity dimension elements and refuse to even try and show you that data.

However, if you were to create an TM1 Excel workbook off of a slice from this cube and/or use DBR formulae you could actually retrieve some of the data from the "GL" cube that this user had access to via Cell Security. Is this ideal? Not really, but if you did need to allow someone to reconcile accounts who normally would not have any access to all entities/business units, you could use Cell Security in this way. The problem is they'd have no ability to browse the data on their own - you'd have to provide them with a static report of some kind that presented what they could see.

Regards,
Mike

[Michel Zijlema]

Hi Mike,

I indeed didn't think of this 'backdoor'. I did some heavy testing on the interaction of the different security objects, but using the cube browser. IMO this backdoor should not be there (but of course the security setup should be unambigious too). It's not good to have the security behave different in different interfaces.
One message that can be derived from this discussion is to keep the security as simple as possible, don't overcomplicate things and only use cell security (overriding) as a last resort.

Michel

[Paul Segal]

Please note that if you give none rights to a certain element using dimension element security, it is not possible to override this using cell security - the cell security will only be applied to the 'available' elements.

Well, this is a pain, although I can see the logic.

I have a case where I have a dimension used in two cubes where I want people to be able to see a greater set of the dimension elements in Cube A than Cube B. We're also using integrated login. As I see it I have two options:

1. Give those affected an alternate login with greater dimension element rights, but only access to Cube A and not Cube B. Major disadvantage is they will need to go and uncheck the integrated login option and login using TM1 security.
2. Give those affected an action button or similar which switches their rights between more elements/Cube A and less elements/Cubes A and B via a TI process.

I can't say I'm desperately keen on either. Anyone else have any better ideas?

[lotsaram]

Only way to do it "properly" is to clone the dimension and use different dimensions in each cube and therefore be able to apply different element security in one dimension (& cube) vs. the other. Whether you can change the design to incorporate the extra dimension is another question ...

[Paul Segal]

Yeah, I thought that might be the case. It's a fair amount of work for not many users, so I may go with option 2 until and if they get into double figures.