TM1 Forum

I think the answer is no, but thought I would ask anyway... Is there a way to prevent some admins having access to one cube in a model?

I know I could put the cube in different model, however I want the sensitive cube to pass data (salaries aggregated to department level) back to the the non-sensitive cube. If they were in seperate models the only way I can see to pass data is via a data export/import which is not secure.

We have two system accountants that develop basic rules, therefore admins, that should not be able to see this information at leaf level.

This doesn't necessarily help with your question but...

if the 2 System Accountants are only developing "basic rules" is it not preferable to in fact defer that responsibility to someone else considering that the licence for a Developer is circa £10k as compared to £1500 for a standard read/write user (that is last time I checked anyway.)

Hmm possibly but we got a pretty good deal on the licenses and it's a big system.

I want to restrict sensitive information to some users which is easy, but lock out all but one admin which I cant think how to do.

How about adding said 2 users to a new group "AlmostAdmin" and removing them from "Admin"...

... whilst setting "AlmostAdmin" to have Admin access to all cubes (except the one in question.)

They would also need Admin access to all dims, process etc.

declanr wrote:How about adding said 2 users to a new group "AlmostAdmin" and removing them from "Admin"...

... whilst setting "AlmostAdmin" to have Admin access to all cubes (except the one in question.)

They would also need Admin access to all dims, process etc.

That would work for cubes, even dims but it won't work for processes and chores as the only options for non-admin users are Read or None. If they don't write TI then perfectly acceptable.

AmbPin wrote: but lock out all but one admin which I cant think how to do.

is that not a really bad idea from a business continiuity perspective? what happens when said person is on holiday, off sick, run over by a bus....

Lotsaram,
Cheers for the clarification.

AmbPin,
Of course that is just a way to solve the specific question but personally I would point to my earlier post as I tend to recommend that users have the minimum security access possible to do their jobs well. Although this must be combined with a minimum of 2 full Admin users for reasons as pointed out by Steve Vincent.


Does anyone know how the IBM licencing works in regards to giving a user partial Admin access?
I imagine in the case of having Admin access tot he majority of cubes a user would need a full on "developer" licence but at what point does that stop? For example what if a user is standard read/write with admin access to 1 dimension?

Simple answer - there isn't. TM1only has 2 types of license, to get access to various menus that are greyed out to a client you must have the admin license. There is no halfway house - you can limit an admin to just securityadmin or dataadmin (detailed in the help guide) but you still require the admin license in order to use them.

declanr wrote:How about adding said 2 users to a new group "AlmostAdmin" and removing them from "Admin"...

... whilst setting "AlmostAdmin" to have Admin access to all cubes (except the one in question.)

They would also need Admin access to all dims, process etc.

This almost works, but if they have security admin then they can give themselves access to the cube I want hidden from them.

If they are only writing rules for a specific few cubes, just give them Admin access to those cubes and give them write access to everything else.

If you need them to be able to change security for other users in addition to having admin access to data then I doubt you would have any option other than giving them full blown Admin access.

declanr wrote:If they are only writing rules for a specific few cubes, just give them Admin access to those cubes and give them write access to everything else.

If you need them to be able to change security for other users in addition to having admin access to data then I doubt you would have any option other than giving them full blown Admin access.

There's always a way (well almost, but in this case there is). You can always manage security in other cubes (or an external database) that these power users have write access to where the confidential data is cube is excluded from security assignments. A chore or process then can pick up the assignments from the other cubes or external source and apply in the TM1 model without the users needing SecurityAdmin rights.

lotsaram wrote:

declanr wrote:If you need them to be able to change security for other users in addition to having admin access to data then I doubt you would have any option other than giving them full blown Admin access.

There's always a way (well almost, but in this case there is). You can always manage security in other cubes (or an external database) that these power users have write access to where the confidential data is cube is excluded from security assignments. A chore or process then can pick up the assignments from the other cubes or external source and apply in the TM1 model without the users needing SecurityAdmin rights.

Thnak you, that is the conclusion I had come too also.

One option here may be to look at Replication? You could have a separate model that includes the confidential detail, then perhaps have a process which replicates across data from a summary cube?

I don't know whether you have a seperate development environment or not but if you have
the easy option seems to be to only give them admin level access to the dev environment (and not make the sensitive data available in there).

Jeroen

Jeroen Eynikel wrote:I don't know whether you have a seperate development environment or not but if you have
the easy option seems to be to only give them admin level access to the dev environment (and not make the sensitive data available in there).

Jeroen

Thanks but this option would prevent the other admins doing group/user administration on the live database.

Martin Ingram wrote:One option here may be to look at Replication? You could have a separate model that includes the confidential detail, then perhaps have a process which replicates across data from a summary cube?

Thanks, this is almost the option I have chosen but have used custom TI scripts to replicate the bits of the model that I want moved back and forth.

Sounds like a plan