Ogram wrote:Wim Gielis wrote:
Do not use that ConsolidateChildren, have a look at element security. Not dimension security.
Thank you, you confirmed what I was thinking about. Could you please further clarify the following to make sure I really got the gist of things:
1. If user belongs to two different CAM groups, user will have the highest permission level available in those groups.
2. If there are different restrictions affecting a single cell (e.g. Cell Security cube grants WRITE, Dimension security grants READ and Element Security grants NONE), the highest restriction will be applied. In the example, it would effectively hide the element since the user would have NONE level rights to it.
3. The application will automatically apply all the security elements available, for example it will use both the cube-specific Cell Security cube and the element/dimension-specific security cubes to enforce security if they are available.
4. If I set a consolidation element to READ and leave the lower level elements blank, will those blank elements count as having NONE, READ or WRITE-level access or is the access in this case decided by security restrictions inherited from other security sources
5. If I want to prevent users from entering data into consolidated cells, I should be able to achieve this by
- Adding a rule to the automatically created Cell Security cube (that only contains the approval hierarchy and }Groups) which changes all the C-level elements to READ
- Adding a similar rule to the Element Security cubes for each dimension that contains C-level elements and is used in the applications visible to the end user
Thank you. I wanted to write this out in detail just in case someone else might be looking at a similar problem. IBM documentation is a tad prone to either ambiguity or hitting everything but the mark.
You are aware that users
cannot write to consolidated cells, right?
The two exceptions are:
(a) If the element in the last dimension is an S (String (that is, text)) type; or
(b) If you are doing a data spreading Clear function.
In any other case they can hammer away until the cows come home and they will never be able to punch a number into a consolidation element.
If you're trying to prevent input into string elements then as Wim said, you use Element security. You can assign "READ" access to every element that is higher than level 0. This can be done either manually or by a rule, though to be honest I dislike using rules for security unless there is a need to make the security dynamic in some way.
Let me rearrange your explanation of security.
TM1 operates on a "least restrictive" basis. That means that if the user is in two groups, and group 1 says they have write access and group 2 says that they have read access for the same type of security (be it cube, dimension or element), they have write access.
If group 1 says they have read access and group 2 says that they have no access, they have read access.
This applies no matter whether it's cube, dimension or element security.
Cube security determines the access that they have to a particular cube. If they have no access to it, then the security assignments for dimensions and elements is academic.
Dimension security determines whether they can see the dimensions. If they have read or write access to a cube they should have read access to all of the cube's dimensions. If you assign cube security through the GUI this is taken care of for you.
Element security determines whether they have read or write access to the specific elements. To be able to write to a cell the user must have WRITE access to the relevant element of EVERY dimension. They will have this by default for any dimension which does not have element security on it. For any dimensions which DO have element security, they must be assigned permission separately. If they have WRITE access to the elements of one dimension in the cube but only READ access to elements of another dimension, then they have only read access to that cell. This is not a violation of the "least restrictive" rule because the element security for each dimension operates independently of the other ones.
Also security doesn't "cascade down" as I think you were suggesting in point 4. If you set security for a consolidation element it doesn't automatically apply to the elements below. (Consider what would happen if you had multiple hierarchies and in one the parent element had READ access, and in another it had WRITE access; what security would apply to the child element? For that reason security needs to be set for each element separately, whether by rules or manually.)
In summary then to write to a value they must have:
WRITE access to the cube;
At least READ access to all of the dimensions; and either
The dimensions should not use element security OR they have WRITE access to the elements for every dimension which uses element security.
Oh, and unless the element in the last dimension is a String type, NONE of the elements can be consolidations.
Security is a bit of a black art but with a little practice and experience it's not that hard to get your head around.