10.3 - Issues with rules in the }Groups and }Clients dims

[mvaspal]

Hi
Just upgraded to 10.3 Planning Analytics, and wanted to call your attention to test your rules in cubes with the }Clients and }Groups dimension.

We use native security, and for example this has no effect in an element security for Companies dim:
[] = S: IF(!}Groups @= !Companies , 'WRITE' , 'NONE');

or in a Divisions dim where the security input is in another cube:
[] = S: IF(DB('zSecurityDivisions', !Divisions, !}Groups, 'nValue') > 0 , 'WRITE' , 'NONE');

We use native security, and user group names are the same as company names. We had to hardcode all companies on the LHS of the rule to make it work, i.e.:
['}Groups':{'Company1','Company2'}] = S: IF(!}Groups @= !Companies , 'WRITE' , 'NONE');

We also had issues with }Clients dim where we had to create a cube with a "Clients" dim, and feed into the cube with the "}Clients" dim (not all rules, it was related to STET somehow)

So just be sure you test rule-based security well before upgrading

Matyas

[ardi]

Thanks for sharing, it looks like TM1 Development team is in big trouble. I really miss the older versions of TM1 ( 9.4 and prior ). Every new version IBM has released, has created major impacts for us

[lotsaram]

We use native security, and for example this has no effect in an element security for Companies dim:
[] = S: IF(!}Groups @= !Companies , 'WRITE' , 'NONE');

This is not good. I hope you reported this as a bug?

[paulsimon]

Hi

I wonder if TM1 10.3 is getting confused on the LHS? Have you considered renaming your Groups with a Grp_ prefix?

If it worked in 10.2 and it doesn't in 10.3 then that is a bug, but the above might be a workaround.

Regards

Paul Simon

[mvaspal]

Hi
Yes we did open a ticket.

Thanks Paul for your advise, I had literally just a few minutes to fix this as users were waiting to access their reports. So just fixed it in 10 mins and did not think of further solutions yet, but your idea is well worth a try!

Btw, also be sure you test your action buttons after the upgrade! Some of them (could not find a logic/pattern yet which are impacted) lost the server reference, and parameter references. So after you upgrade, be sure you open all of these and check if they work correctly. We recreated all these buttons one by one as it seemed to be quicker (ca. 15 sheets with ca 30 buttons) than communicate with Support. We will open a ticket for this too, soon.

[mvaspal]

Added a test user group with the prefix UG_, and then the rule:
[] = S: IF(!}Groups @= 'UG_' | !Companies , 'WRITE' , 'NONE');

did not help.

[paulsimon]

Hi

We use native security, and for example this has no effect in an element security for Companies dim:
[] = S: IF(!}Groups @= !Companies , 'WRITE' , 'NONE');

Can you clarify what you mean by has no effect? What are you seeing in the }ElementSecurity_Companies cube? Are you seeing a blank or are you seeing NONE when the Group matches the Company, or are you seeing WRITE but even after doing a Security Refresh a user in the appropriate Group is not able to write to the related Company?

I know that you have tried this with one Group with a UG_ prefix but to really check that there is not an issue due to Groups and Companies having the same name, you should probably look at a dimension that has elements that don't have the same name as the Group. If that works then your answer is to remove all your existing Groups and re-create them with a prefix so that they are not the same as the Element Name.

Having said that, your other rule where you are referencing another cube does not work either. However, can you clarify what you mean by doesn't work?

You say that you are using native security. Has the server ever used CAM security?

Regards

Paul Simon

[mvaspal]

Hi

does not work = white cells in the element sec cube