TM1 Forum

Hello board members,

What do you think of the following situation? It deals with security and zero suppression.

A client has 2 kinds of security groups: one type of groups for Cost center security, and one type of groups for Projects security.

There is 1 cube that makes use of both dimensions, Cost center and Projects.

The requirements are that:

- a cost center owner should have read access to only his cost center, but for all projects. None access to other cost centers.
- a project owner should have read access to only his project, but for all cost centers. None access to other projects.
- a TM1 client can be a CC owner and a Project owner, or one of them

Given this, we need to write rules on the }CellSecurity_cubename cube. We implemented this, and it works perfectly.

However, there are about 200 Projects and 100 Cost centers. If you set up a view with all cost centers and all projects, you see a large view which is normal since the combination matters. You see nothing in cells to which you have none access.

Zero suppression:

The zero suppression will not take away rows or columns that have a 0 for a particular CC / project combination that you can see, IF there are non-zero values in other combinations to which you have NONE access. If that would be the case, the view would be much smaller and actually usable, now it's not usable for a client on the web e.g.

The issue:

Shouldn't the zero suppression also hide rows/columns to which you have none access (but that are not zero)?

Any thoughts on this?

Thanks,

Wim

Hi Wim,

I can see where you are coming from if you have NONE access definied at the cell level and the whole row/column is not available for you to see then you would expect the cube viewer to suppress that row even though there would be data available if you did have access.

As you have found it does not work like this. Zero suppression works on data and cell level security works on cells, there's no cross checking between the two.

I tend to shy away from very complex security as you can end up building a complete application in it's own right just to manage the security. I don't think I have encountered something like you want before so I can't think of an alternative approach. My only thought is that if you really need cell level security and if element level security would work for you. If there is a whole row/column of blanks then the user has no access to the CC/ Project, so element level security would work. Once the you have no access to elements rather than cells then you won't see the rows anymore.

HTH or someone else can offer you some guidance.

Cheers,

Wim

- a cost center owner should have read access to only his cost center, but for all projects. None access to other cost centers.
- a project owner should have read access to only his project, but for all cost centers. None access to other projects.
- a TM1 client can be a CC owner and a Project owner, or one of them

I can see why you need cell level security. The problem comes from the fact that a client can be both a Cost Centre owner and a Project owner.

P CCCCCCCCCCCC

C PPPPPPPPPPPPP

If you just use Element Security then you have to give access to all centres and all projects, and you can't represent the restriction of all projects for Centre X and all Centres for Project 1.

If there are very few cases were a user is both, and most are one or the other, one option would be to create two TM1 User Ids. They you could use Element Security rather than Cell Security.

We have a similar issue here with Entity and Cost Centre.

With Element Security if User A has WRITE access to Entity 1 and 2, and WRITE access to Centre X and Y, there is no way to show that User A should only be able to Write to Entity 1 with Centre X, and Entity 2 with Centre Y, but should not be able to write to Entity 1 with Centre Y.

Our solution was to combine the Cost Centre and Entity in to one dimension in the Planning cube. We still have the Entity dimension, but we now have a Centre-Entity dimension, in which the base level element is a combination of the Centre and Entity Code. This then consolidates up to the Centre level and then up the Centre hierarchy as normal. The fact that the base level is a Centre-Entity combination allows us to give Write access to User A to 1-X and 2-Y, but not 1-Y.

It also gives us some advantages since in reality a Centre Entity combination is a really a distinct concept and has its own manager etc, distinct from the same Centre in another Entity. When planning they just pick from the Centre-Entity dim, but higher level reviewers still have the Entity dimension if they want to get a view at Entity level.

I am not sure if that would work for you.

I have always tended to avoid cell level security, but from what you are saying the zero suppression issue is a bit of a show stopper for cell level security. Are you sure that you are not mixing both Cell level and Element level security? The cell level tends to override the Element security with some odd results.

If the cubes are only used for reporting, another approach might be to create a virtual cube using rules, so the main cube only has security on the project dimension, and the virtual one only has security on the centre dimension. Those users that are both Centre and Project owners would get access to both cubes, but in either cube the appropriate restriction would apply.

Regards


Paul Simon

Thank you both, I will read your suggestions carefully.

Wim