Default Element Security to 'Read'

[tm1newb]

Using 10.2.2 FP 4. I have an dimension called 'ID' that is continually being added to everyday via a TI process

The problem is that when the new items are added, TM1 defaults these to 'None' access privileges and I cannot figure out how to set a default so that the entire dimension has 'READ' privileges?

Things I have tried:
}DimensionSecurity set 'ID' to 'Read'
Also tried in }ElementSecurity_ID rule of '[]=S:'Read';'

Does anyone else happen to have ideas? Thanks!

[declanr]

If the whole dimension should be read for every group just delete the element security cube (with a stop delete start of course.)

If varied security is required then TI it via looping the dim after or as part of the process that updates the dim.

[tomok]

If your intention is that all the elements in that dimension should be READ then you don't need an }ElementSecurity cube for the ID dimension. Simply make that element READ by putting the following rule in your }DimensionSecurity cube:

Code: Select all

['ID'] = S:'READ';

Remember that you'll need to refresh security before it will take effect.

[jwilkins]

If your goal is to secure data in cubes that use the ID dimension, then dimension security isn't actually taken into account. Cube, element and cell security are all that are considered. Likely the reason your element security rule did not work is the point that Tom mentioned. After you update the ID dimension from the TI process, you'll need to do a security refresh.

I believe there's a TI function ( SecurityRefresh()?) that you could call in the Epilog of your process that updates the dimension.

[paulsimon]

Hi

The problem with using rules is that you need the security refresh to make them take effect which can take a long time if you have a lot of rule based security on a big model. That is not to say that it is not a valid approach. It depends on the circumstances.

An alternative is to use ElementSecurityPut on the Data Tab of the dimension build routine. This makes the security automatically take effect without the need for a SecurityRefresh. A downside is that it does not populate the }ElementSecurity cube for the dim. To get around this, I also do a CellPutS to the }ElementSecurity cube. One thing to be careful of is that if you use CAM Security, you need to use the raw CAM ID rather than its Alias, with the ElementSecurityPut statement.

I have a more elaborate scheme which uses a separate cube to allow security to be set at a higher level in the hierarchy, with changes then cascading down the hierarchy. It then compares this to the }ElementSecurity cube and then only does an ElementSecurityPut for those elements that have changed their Access Right.This helps to minimise locking and the need for changes to the security cube. It combines the advantages of a rule based scheme with the advantages of stored data.

Regards

Paul Simon

[jwilkins]

Assuming the desired out come is as stated (that "the entire dimension has 'READ' privileges") you would be much, much better off simply setting each of the cubes that uses the ID dimension to 'READ'. This is effectively the same and I'm not sure why it didn't hit me before now.

If you do have existing more complex security requirements, and you simply want new elements to be set to 'READ', Paul's approach of using ElementSecurityPut instead of a rule + security refresh is almost certainly the way to go.

I have a more elaborate scheme which uses a separate cube to allow security to be set at a higher level in the hierarchy, with changes then cascading down the hierarchy. It then compares this to the }ElementSecurity cube and then only does an ElementSecurityPut for those elements that have changed their Access Right.This helps to minimise locking and the need for changes to the security cube. It combines the advantages of a rule based scheme with the advantages of stored data.

This is an interesting approach. Is it not inefficient to compare every cell in the duplicate cube to the }ElementSecurity cube? Although, I suppose compared to refreshing security on a large/complex model it's comparatively fast and significantly less intrusive. It also seems like having a duplicate of the security data taking up valuable memory wouldn't allow this approach to scale in models with very complex security requirements.