Cell Security on Drill through

[hiraniha]

Hi All,

Looking for some suggestions.

I have been asked to investigate Drill through to an Oracle database for some employee Actuals, which is simple enough using the functionality in TM1.

The actual employee cube has cell security so that users who don't belong to certain groups can't see employee data which is sensitive.

However I have noticed that the drill rules cube doesn't incorporate any security from the cell security cube, I was hoping that it would stop a user from doing a right click -> Drill on a cell that appears greyed out for them. But a user can in fact drill back the oracle source on a cell that they don't have access too.

I have tried cell security on the }cubedrill cube but that makes no difference, in fact the user doesn't need any access to the }cubedrill cube to drill they just need read access to the drill process.

Any other alternative ideas would be appreciated?

regards

[lotsaram]

You will need the rule in the drill string cube to be conditional based on inspecting the cell security cube. If the access is "NONE" then make the drill string empty.

The issue is in determining what the relevant group to query against in the cell security cube is. This is a case in point where the TM1User function can be useful in a rule as you could have an attribute against the client holding the relevant cost center assignment which determines the group. If you can do that then the problem is quite easily solvable. If you have no way of knowing which group to look at then it's going to be more difficult and you might need to create a separate numeric security lookup cube with a copy of the groups dimension with a total in order to be able to query permissions for the sum of all of a user's groups.

[paulsimon]

Hi

Another alternative is to restrict the elements that the user can see using ElementSecurity. If they can't see the cell, they can't drill from it. It is quite common to combine Element and Cell Security for this reason.

Regards

Paul Simon

[hiraniha]

Thanks both for the replies,

lotsaram:
Users belong to multiple groups some that control individual elements access, others that refer to a node in the hierarchy for the controlling dimension. I'll see if I can work on what you are referring to to use the TM1User function.

paulsimon:
element security is not an option as other cubes that don't need to restrict at this detailed employee level still require read access to see other P&L accounts and also they are fine to see roll up numbers in a labour summary cube, just not the detail of an individual in the detail cube.

Personally I view this as a bit of a 'bug' as most of the other 'options' on a right click seem to take the cell security into account, therefore the drill should do the same thing really. Perhaps I should raise it to IBM to consider resolving. Especially if all other alternatives are elaborate workarounds that then have to be devised due to lack of correct functionality.

[paulsimon]

Hi

Without seeing the dimensions in your cubes and exactly which elements you want to restrict it is hard to comment.

Are you perhaps sharing the measures dimension between the detail and summary cubes?

If not then I cannot see why you cannot apply element security to limit access to the sensitive parts of the employee data.

Is this in a measures dimension or do you have this in the Nominal dimension?

If you include more details we might be able to help more.

Regards

Paul SImon