TM1 Forum

Hi All

I am interested to hear your thoughts on the following issue.

We have a setup where we run FAP to publish a cube in TM1 from Cognos Controller. We then create a reporting cube from the FAP cube. The security is taken over too.

We then publish this reporting cube to BI so that we can produce reports from it.

An issue has arisen whereby security in TM1 doesn't seem to work properly in BI. An example will hopefully explain this a little better.

Suppose I have the following consolidation within my "company" dimension:


All Companies
-Rollup1
---Co1
---Co2
---Co3
-Rollup2
---Co4
---Co5
---Co6


If UserA has access to READ only Co2 and Co4 data, and is denied access to all other nodes and consolidations, TM1 simply tells the user that he has no access in the company dimension editor and simply retrieves in Perspectives the data for Co2 and Co4 only.

However in BI, we are seeing that the user only sees data for Co2, as it seems the security prevents BI from trawelling further down the hierarchy and identify that Co4 is also readable by the user.

This does sound strange and before we even look at investigating cell level security I wondered if anyone had found this issue and how they overcame it.

Thanks
Ajay

Ajay wrote:This does sound strange and before we even look at investigating cell level security I wondered if anyone had found this issue and how they overcame it.

I haven't found a walkaround other than these two options:

1) Build your dimension with alternate hierarchies, so that for any user security restriction there is always an unbroken chain of parent-child relationships the user can trawl to all the elements he should have access to. This may have varying levels of complexity, depending on your setup. In the extreme case each user might have their own alternate hierarchy that only they can see (and can't see anything else), but whether this is practical is another matter.

2) Ditch element security altoghether and do it with Cell Security. Users will then be able to see the full dimension tree, but they will see blanks for the elements they have no access to instead of numbers. You can use zero suppression to hide these elements from the actual reports if you need to.

Thanks QML

Due to the business requiring some customised rollups I think we may not get away with user based hierarchies. we're going to have a look at the cell security but my only concern there will be performance, as the model is large and complex already.

Additionally, we're thinking that perhaps the introduction of a flat structure of all elements under a single parent may work, eg.

Every Company
--Co1
--Co2
--Co3
--Co4
--Co5
--Co6

Using this as the prompt in the Report Studio reports, and then in the rows of the report applying zero suppression may work, it just doesn't give us a nice solution for users who will be using Analysis Studio, who no doubt would want to drill down from the hierarchy in the original post.

Ajay

Ajay, cell security is not nearly as evil as some would present it. It has its uses. The size and complexity of your model doesn't really matter much in the context of cell security - I have successfully used rule-calulated cell security with complex, big cubes running into the large tens of gibibytes. You need to remember that the overhead is proportional to the number of cells displayed in a single view/report. If your reports are not gigantic then you won't even notice the impact of cell security on performance. I definitely recommend at least trying it out. Also, version 10.2 has introduced new cell security cubes that don't have to have all the dimensions of the main cube, but only the relevant ones. This can help simplify the set-up somewhat.

Hi Kamil

Old skool thinking on my part regarding the cell level security, we'll give that a go and see if it works.

Cheers
Ajay