DimensionSecurity Rules not being fired

[tm123]

Hi guys,

I am on Planning Analytics Version 2.0 (TM1 Build Number: 11.0.00200.998) and I am experiencing a strange issue.

I need to secure Dimensions so I have written rules for }DimensionSecurity cube, but for some strange reason, the Ruled cells are not being populated. There is no feeder or anything, and If I try to key-in some text in the Ruled Cells, TM1 throws an error saying "Not a number value"

Attached is a screenshot with the Rules ( I have simplified the Rules just for testing purposes )

This happens randomly, usually after I make changes to other Security Cube Rules and click of SecurityRefresh, but I cant reproduce it all the time

I have similar rules for }CubeSecurity and }ProcessSecurity, but I have not seen this issue in those cubes?

Any Idea?
Thanks

DimensionSecurity Rules.GIF (39.03 KiB) Viewed 9678 times

DimensionSecurity Cube View.gif (63.43 KiB) Viewed 9678 times

[tomok]

That's some of the weirdest looking syntax for a rule on the }DimensionSecurity cube I've seen.

Code: Select all

['{Clients'] = S:'WRITE';
['{Groups'] = S:'READ';
['{Dimensions'] = S:'READ';

Do you really have groups called }Clients, }Groups, and }Dimensions?????? That's what part of your rule is doing, it's assigning rights to those three specific groups.

[Wim Gielis]

Euh Tom, the OP assigns (the same) rights to all groups on the dimensions that are mentioned. They are not group names but dimension names. Also it’s } instead of {

Which is not to say that I agree with these rules or the way of working.

[tm123]

That's some of the weirdest looking syntax for a rule on the }DimensionSecurity cube I've seen.

Code: Select all

['{Clients'] = S:'WRITE';
['{Groups'] = S:'READ';
['{Dimensions'] = S:'READ';

Do you really have groups called }Clients, }Groups, and }Dimensions?????? That's what part of your rule is doing, it's assigning rights to those three specific groups.

Hi Tom,

Those are Dimension Names, so I just wanted to illustrate with en example what I am experiencing. These dimensions exist in each model that's why I used those, but the rule that does not get fired is the rules that apply to the whole cube ( see the lines below )

Code: Select all

[ ] = S: IF ( SUBST ( !}Dimensions , 1 , 1 ) @= '}' , 'NONE', CONTINUE ) ;
[ ] = S: 'WRITE' ;

Thank you

[Steve Rowe]

I've seen issues in the past with "stuff" that hangs off the }Dimensions dimension. My understanding of the trigger for this is that the }Dimensions dimension can be fully deleted and rebuilt under some circumstances, like a restart.

I hit this once a long time ago with some attributes on the }Dimensions dimension getting cleared on a restart. Since then I've avoided touching this dimension so I don't know if this still happens.

Might be root cause though, if the }Dimensions dimension is deleted on restart (or otherwise) by the engine and related objects rebuilt then this would result in the rule sheet becoming detached.

[tm123]

I've seen issues in the past with "stuff" that hangs off the }Dimensions dimension. My understanding of the trigger for this is that the }Dimensions dimension can be fully deleted and rebuilt under some circumstances, like a restart.

I hit this once a long time ago with some attributes on the }Dimensions dimension getting cleared on a restart. Since then I've avoided touching this dimension so I don't know if this still happens.

Might be root cause though, if the }Dimensions dimension is deleted on restart (or otherwise) by the engine and related objects rebuilt then this would result in the rule sheet becoming detached.

Thank you Steve,

I can guarantee that the Dimension is not being deleted on restart or anything, actually the TM1 Instance has not been restarted this week at all, but this issue has happened a couple of times each day, basically when I change Rules for some other Security Cubes, and after I click on Refresh Security, the dimension security is gone. I still can see the rule, and also the Rule applies for the Lines where I am specifying the Dimension Name (eg. ['}Clients'] = S: 'READ' works fine), but not for the Generic Rules ( eg [ ] = S: 'READ' does not get fired, and there is no STET rule anywhere in my Rules )

The problem is that if I delete the Rules and also I delete the }DimensionSecurity cube from my model, then non-admin users cannot open any of the cube views, so I need to populate the }DimensionSecurity somehow. I know I can write a TI process to populate that cube, but I don't understand why the Rule is not working

By the way, in my prior TM1 Implementations, I have used the same Rules and never had this issue

Thanks again

[tomok]

I've seen issues in the past with "stuff" that hangs off the }Dimensions dimension. My understanding of the trigger for this is that the }Dimensions dimension can be fully deleted and rebuilt under some circumstances, like a restart.

I hit this once a long time ago with some attributes on the }Dimensions dimension getting cleared on a restart. Since then I've avoided touching this dimension so I don't know if this still happens.

Might be root cause though, if the }Dimensions dimension is deleted on restart (or otherwise) by the engine and related objects rebuilt then this would result in the rule sheet becoming detached.

I don't know if the }Dimensions dimension is deleted but I do know for a fact that it is rebuilt on every server restart. If not, how would it ever work if you were to copy in a .dim file like during a promotion if you didnt have an instance with the EXACT same list of dimensions and you copied in the }Dimensions dimension as part of the promotion?

[tm123]

I've seen issues in the past with "stuff" that hangs off the }Dimensions dimension. My understanding of the trigger for this is that the }Dimensions dimension can be fully deleted and rebuilt under some circumstances, like a restart.

I hit this once a long time ago with some attributes on the }Dimensions dimension getting cleared on a restart. Since then I've avoided touching this dimension so I don't know if this still happens.

Might be root cause though, if the }Dimensions dimension is deleted on restart (or otherwise) by the engine and related objects rebuilt then this would result in the rule sheet becoming detached.

I don't know if the }Dimensions dimension is deleted but I do know for a fact that it is rebuilt on every server restart. If not, how would it ever work if you were to copy in a .dim file like during a promotion if you didnt have an instance with the EXACT same list of dimensions and you copied in the }Dimensions dimension as part of the promotion?

That is true for other dimensions also ( }Cubes, }Processes, }ApplicationEntries etc) but I do not see the same behavior on the Security Rules for those objects.

It might be a bug on the version I am working with, otherwise it's like a ghost

[lotsaram]

The problem is that if I delete the Rules and also I delete the }DimensionSecurity cube from my model, then non-admin users cannot open any of the cube views, so I need to populate the }DimensionSecurity somehow. I know I can write a TI process to populate that cube, but I don't understand why the Rule is not working

The issue you are describing does sound like a bug.

But why do you need dimension security at all? If the }DimensionSecurity cube is deleted then the default security level for ALL dimensions is READ. The only reason you would ever need to apply dimension security would be to hide a dimension from some user altogether because the element names themselves are confidential in some way. Not very many models have this requirement and so have no need for dimension security.

[tm123]

The problem is that if I delete the Rules and also I delete the }DimensionSecurity cube from my model, then non-admin users cannot open any of the cube views, so I need to populate the }DimensionSecurity somehow. I know I can write a TI process to populate that cube, but I don't understand why the Rule is not working

The issue you are describing does sound like a bug.

But why do you need dimension security at all? If the }DimensionSecurity cube is deleted then the default security level for ALL dimensions is READ. The only reason you would ever need to apply dimension security would be to hide a dimension from some user altogether because the element names themselves are confidential in some way. Not very many models have this requirement and so have no need for dimension security.

Actually I tried deleting the }DimensionSecurity and after that, non-admin users cannot see any dimensions and therefore they cannot open any of the CubeViews

after deleting the }DimensionSecurity, if I go to Dimension Security Assignment grid, the default access for all Cognos BI Groups is "NONE"

[pandinus]

This is possibly because the rule also applies security to the ADMIN, DataAdmin and SecurityAdmin groups. This cannot be and TM1 does not know how to handle this correctly, leading to strange and inconsistent behavior.
Same weird stuff happens when you run a TI process and try to set security for one of these groups.
Try to exclude these groups from the rule and see if that helps.

[tm123]

Thank you, good suggestion

I actually gave up on that Rule so I write a process to populate the }DimensionSecurity cube, so far has not given any issues but for such a simple Rule, I had to complicate little bit my model just because the Rule was not doing what it is supposed to do.

[tony.wijaya]

Hi,

Just want to share, i encountered the same issue before. If i am not mistaken, it happened to me every time there is a new group created or removed via TI. To fix that, i created a separate TI to load the rule from file again and call put security refresh. So basically, after the group maintenance is executed, i will trigger this TI to reload the rule for this dimension security.

Code: Select all

RuleLoadFromFile( '}DimensionSecurity', '}DimensionSecurity.rux');
SecurityRefresh;

I am not really sure why the group creation or deletion can cause the rule become invalid, but the ruleloadfromfile saved me.

Hope it can be helpful

[Wim Gielis]

Thank you tony.wijaya

[Elessar]

tony.wijaya,

This is really strange. You can use the audit log to determine the culprit