Building Security Dimension

[Toto]

Hello,

I want to build the security for the client/groups. E.g. I have three users for UK:
User Anton= manages London (only he and his supervisor "Dan" should see the figures)
User Bert= manages Manchester (only he and his supervisor "Dan" should see the figures)
User Caesar= manages Birmingham (only he and this supervisor "Dan" should see the figures)

The same hierarchy for Sweden with the supervisor John.
John and Dan report to the overall chief Tom, who can see the figures from John and Dan and all managers in all countries.


Should I create one group per each user in the UK(Anton, Bert, Caesar)? Is there a different approach with 100 users?
Or should I create one group for all UK-users (Anton,Bert,Caesar) and create the report in the way the user can only see his own figures?

What about John and Dan? Should they belong to the same group?

I thougt about this:
Group1: UK_Managers
Group2: UK_Supervisor
Group3:Sweden_Managers
Group4:Sweden_Supervisors
Group5:CEO

Is that correct?

Thanks a lot for your help!

Toto




a,b,c which belong to UK d,e,f which belong to Sweden and both belong to Europe.
How the groups should look like: a, b

[Martin Ryan]

Depends on if it is "should only see" or "must only see". If it's "must" then you'll need to create separate security groups for each of the different users. If it's "should", then setting up a UK group and a Sweden group and default subsets for each of your users will make life a bit simpler for you. Though security isn't really all that difficult if you set up a flat file and use TI to manage it for you.

If you go the subset method instead of security, and if they're using Excel for their reports then I sometimes create subsets named "username" for each user and use the excel function =tm1user("server") to retrieve their username and use that to determine the subset.

As an aside, if you have to go the security way I'd suggest you call your security groups "London", "Manchester" etc instead of "Anton", "Bert" etc so you can easily handle staff changes/additions.

Martin

[Toto]

Hello Martin,

thanks a lot!!

Regards,

Toto

[Toto]

One last question please:

If I decide to have a structure like told before:

"User Anton= manages London (only he and his supervisor "Dan" should see the figures)
User Bert= manages Manchester (only he and his supervisor "Dan" should see the figures)
User Caesar= manages Birmingham (only he and this supervisor "Dan" should see the figures)"

Is it advisable to put a hierarchy in the }Clients-dimension and use this system-dimension in my cubes? Or should I have an "own" dimension with the users and a hierarchy?

Thanks again!

Toto

[Martin Ryan]

Is it advisable to put a hierarchy in the }Clients-dimension and use this system-dimension in my cubes?

No, not advisable. It won't help and will make the data load messier. You'll also have to repeat data, either via rules or TI.

Or should I have an "own" dimension with the users and a hierarchy?

Not sure what you mean here. But there's no need to be adding extra dimensions or hierarchies in addition to the ones you've already got for storing the data. All you're doing now is controlling who can see that data.

Here's a quick step by step guide. If anything's not clear the manual should help (chapter 13 of the 9.5.1 operations guide)

1) Create security groups "London", "Manchester", "Birmingham" and "UK"
2) Put Anton in the London Group, Bert in the Manchester group, Caeser in the Birmingham group and Dan in the UK group
3) Right click on the Region dimension -> Security -> Elements Security Assignments...
4) At the intersection of "London" region and "London" group, set the value to write. Do the same for Manchester/Manchester and Birmingham/Birmingham.
5) Give the UK group read (or write) access to all three cities, plus UK.
6) Make sure all other intersections are "None".
7) You're done.

Personally, if there's more than a dozen groups, I'd do this with a flat file and Turbo Integrator. You can see some of the useful TI Security functions in chapter five of the 9.5.1 reference guide (page 238).

Martin