How to design Clients/Groups and dynamic Elements security

[aro99]

Hi All,

I am new to TM1, so I just want to know is there any easy way to design Clients/Groups in TM1 to satisfy the security controlling?

For e.x., there is Region dimention like

Region
---East
---South
---West
---North

also there are users HQ_User, East_User, South_User, West_User, North_User;
the requirements is HQ_User can see all data, East_User only see data of east region, South_User only see data of south region ...bla,bla

Yes, I can create Groups like East_Region, South_Region, West_Region, North_Region, then in deimension -> elements security assignment, set the Read access of 'East' to East_Region and None to the other elements, then user in East_Region can only view data of East.

But it maybe too complicated if there are 20 elements in the Region dimention and even worse if there are children levels like
Region
---East
------City 1
------City 2
------...
---South
---West
---North

Is that mean to create City level group if the requirement is that some user can only view data of their own city?

What I think is to only create groups like HQ_Group, Region_Group, City_Group, then set users of each level to these group, there is also User/Region relationship loaded to the Cube, then when the user login to TM1 APP Web, get the reigon of login user and dynamicly filter the data of regions he can see.
Is that possible?

Thanks.

[Alan Kirk]

I am new to TM1, so I just want to know is there any easy way to design Clients/Groups in TM1 to satisfy the security controlling?

For e.x., there is Region dimention like

Region
---East
---South
---West
---North

also there are users HQ_User, East_User, South_User, West_User, North_User;
the requirements is HQ_User can see all data, East_User only see data of east region, South_User only see data of south region ...bla,bla

Yes, I can create Groups like East_Region, South_Region, West_Region, North_Region, then in deimension -> elements security assignment, set the Read access of 'East' to East_Region and None to the other elements, then user in East_Region can only view data of East.

But it maybe too complicated if there are 20 elements in the Region dimention

20 groups are not that many. I'm a believer in as few as possible but 20's no great number.

and even worse if there are children levels

You could add the security at the same time as you add new elements. Or, if the changes are frequent or you don't want to have to remember to do them, you could also use rules to assign security to the children based on their parent. Though I admit that I'm not a fan of that because I regard it as unnecessary overhead. Instead I use a system where I have a security control cube and specify which consolidations are available to which groups, and have a nightly process cascade the security down from the consolidations. There are a few more bells and whistles to it than that but that's the gist of it.

like
Region
---East
------City 1
------City 2
------...
---South
---West
---North

Is that mean to create City level group if the requirement is that some user can only view data of their own city?

If that's the requirement, then yes.

What I think is to only create groups like HQ_Group, Region_Group, City_Group, then set users of each level to these group, there is also User/Region relationship loaded to the Cube, then when the user login to TM1 APP Web, get the reigon of login user and dynamicly filter the data of regions he can see.
Is that possible?

Possible but largely pointless if you want genuine security. If you haven't actually secured the dimension there would be little to stop them from creating their own view of the data. Even if you block them from doing that in the Web views section they could still get hold of a client (or even build one if they're clever enough) and get the information that way. For securing the data, relying on filters that the users can bypass is about as effective as wrapping the data that you don't want them to see in tissue paper and writing "Beware of the Iguana" on it.

To secure, use security.

[aro99]

Thank you Alan, what you mentioned

Instead I use a system where I have a security control cube and specify which consolidations are available to which groups, and have a nightly process cascade the security down from the consolidations. There are a few more bells and whistles to it than that but that's the gist of it.

I guess the scenario is that children can view the same data as parent, right? Whatif children can only view their owner data, I mean a part of the parent's data?
BTW, could you show me any codes to build a such kind of prcocess, thank you.