Why are users given WRITE access to Attributes by default?

[harrytm1]

Hi all,

All this while, I always thought that, by default, users cannot edit attributes in a dimension. They can only read. In other words, users cannot type into a DBRA formula to change an attribute.

However, while I'm exploring a request to allow users to update a specific attribute in a dimension, I found that, under the Element Security Assignment GUI of the }ElemenAttributes_DimensionABC, all user groups are by default given WRITE access.

I tested this out by logging in as an user, then enter some text in a DBRA formula. True enough, the attribute is updated. So does it mean that all along, users can update attributes? I always thought this is an Admin feature only. Thus, if I want to prevent users from changing attributes, I will have to set them to READ? that will be nightmarish since there are so many dimensions to deal with!

Any view on this?

[lotsaram]

Harry - Are you sure? Are you sure you're sure?

Yes by default if no element security is set for a particular dimension then the element security for each element will effectively be "WRITE". This is why when you first look at a dimension in the element security GUI you see WRITE for each element. However this does not necessarily mean users can write to attributes!

Don't for get TM1 has "cascading" security. By default no user groups will have write access to attributes unless this has been granted by an admin (perhaps in error but granted nevertheless).

Default security settings are:
- For a group assign READ or WRITE access to a cube
- This automatically assigns READ access to each dimension in the cube

Note a group does not need WRITE access to a dimension to write to a cube. Write access to a dimension should only be granted in specific cases. What WRITE access to a dimension actually does is set WRITE access to the }ElementAttributes_<dimension> cube. This is what lets users write to attributes! Write access to a dimension does not let the group edit dimension structure - to do this they need ADMIN rights to the dimension.

If more granularity below cube level write access is needed the next "cascade" is element level security on one or more dimensions. Then and only then should element security be applied. Be careful setting element security as once element security is initiated the new default level for any new elements will no longer be WRITE it will be NONE (for this reason rule based element security is a very good idea.)

If that brief explanation doesn't quite make sense have a careful read of the security section of the operations guide.

[harrytm1]

I'm not aware that giving WRITE access on a cube e.g. Cube ABC to a User Group XYZ will allow users in User Group XYZ to write data into cells on elements with READ access only. I always thought that security is maintained through element security.

E.g. if i want to enforce security to a dimension "Bizunit", I need to set up element security for this dim. Write access is given to User Groups to respective elements so that they can write data into cubes with this dim. So does it mean that, in order to enforce security, I should assign READ access with the intent for a User Group to write data in a cube that has been given WRITE access? (Forgive me for being naggy, just want to be clear.)

So I'm wrong all this while! this will explain why a user can update an element attribute since he has WRITE access to the element in the dimension. FYI, the dimension is "Product" and rules are used to dynamically maintain the access.

[lotsaram]

I think you might be confusing element security with dimension security...

I'm not aware that giving WRITE access on a cube e.g. Cube ABC to a User Group XYZ will allow users in User Group XYZ to write data into cells on elements with READ access only. I always thought that security is maintained through element security.

No it won't, on this you are correct. If a group has WRITE access to a cube but only READ access to an element then users of that group will not be able to write data in that cube against that element (unless they are a member of another group that does have WRITE access to the element.)

As a rule don't touch dimension security at all (there is no need unless you want to give non-admin groups the ability to edit attributes).
As a general rule don't touch element security either! The exception is of course when you don't want a group to have WRITE access to all members of the dimension but only to specific elements, that's when you need to assign element security. You should explicitly assign WRITE, READ and "" (blank=NONE) for respective groups.

Check your dimension security to make sure groups do not have WRITE assigned to dimensions as this is not necessary to write to cube data.

By the sounds of it you may have a lot of element security that you don't need. The only way to remove unwanted dimension, element, and cell security is to stop the server, delete the control cubes and restart the server.

I think what I wrote is clear (at least to me anyway). If you're still confused re-read what I wrote and try a read the manual.

[harrytm1]

hi lotsaram,

thank you so much for your detailed and patient explanations. i actually noticed my folly after i posted my reply. Yes, I misunderstood your reference to dimension security with element security.

Sorry for being naggy again, when you state that the dimension security should be set to READ for all groups since this has no effect on the users' ability to write into a group, does it mean that, when I right-click "Dimensions" in the folder tree, selects Security Assignment, in the GUI, I should expect to see READ for all groups?

What I'm seeing right now is WRITE for all groups. Which explains why users can update attributes. I'm not sure why WRITE is assigned to all groups, but seems like I should set them to READ, and then selectively assign WRITE to a particular attribute in a dimension.

Once again, thanks.

[lotsaram]

What I'm seeing right now is WRITE for all groups. Which explains why users can update attributes. I'm not sure why WRITE is assigned to all groups, but seems like I should set them to READ, and then selectively assign WRITE to a particular attribute in a dimension.

What you should do make all dimension security READ. Where a group actually requires the ability to edit attributes then selectively change that group's access to the dimension to WRITE and then if they should be able to edit values of some attributes and not others you should use element security on the }ElementAttributes_<dim> dimension.

By the sounds of it I think your first step should be to delete the }DimensionSecurity cube in its entirety. On server startup the cbe will be automatically rebuilt and groups will automatically get read access to all dimensions used in cubes to which they have read or write access to. This will give you a clean point to start from.

(of course take any advice to delete a control object under advisement, no care or responsibility taken for potential damage, etc, etc. )

[harrytm1]

thanks, lotsaram.

that's what i intend to do. Delete the dim security control cube and then mess with }ElementAttributes_<dim> cube through a rule that populates WRITE to a particular attribute.