Hide Elements From Users AS Well As Administrators

[vinnusea]

HI
I want to hide some elements in dimension and those should be hidden even from Administrator

I have done hiding them from Users who are not Admins>> But
Is that possible in TM1 to Hide elements From Admin ??


Thank you,

[tomok]

Depends on your definition of "hide". If you mean make it so an admin can't see the elements when they open the dimension or browse a cube that includes the elements, then the answer is no. An admin in TM1 CAN SEE AND DO ANYTHING TO THE MODEL. This is just the way it is. However, if the idea is just to keep those elements from showing in a report or view then just create a subset that excludes them. Of course, you can't stop the admin from deciding not to use your subset any more,

[rkaif]

If you will hide anything from the Admins then even you (assuming you have admin rights) will not be able to see it....

The purpose of Admins is fairly simple - they should have access to every everything.

The ADMIN group, which is created for administrative purposes only, should contain only a very small group of trusted TM1® administrators.

If you want to hide something from the Users as well as the Admins then simple don't include/delete it in your model or you can create Groups which have different level of Security rights.

[Martin Ryan]

There are SecurityAdmins and DataAdmins as well as Admin admins. I think this was introduced in your version 9.4.1. You can use this to create some level of control over what an "administrator" can see.

I've recently had a similar problem where are importing Payroll data by person into TM1, but we don't want the TM1 administrators to be able to identify that information back to the person. So we've created a mapping table in the Payroll source system to create an employee ID that is unique to TM1. That ID is non-sensical unless you can map it back to their actual employee ID. To do the reverse mapping we created password protected Excel files that vlookup the TM1 ID back to the Employee ID. It's convoluted, but it does the job.

Martin

[vinnusea]

Thanks Martin ...Thats awesome

[blackhawk]

There are SecurityAdmins and DataAdmins as well as Admin admins. I think this was introduced in your version 9.4.1. You can use this to create some level of control over what an "administrator" can see.

I've recently had a similar problem where are importing Payroll data by person into TM1, but we don't want the TM1 administrators to be able to identify that information back to the person. So we've created a mapping table in the Payroll source system to create an employee ID that is unique to TM1. That ID is non-sensical unless you can map it back to their actual employee ID. To do the reverse mapping we created password protected Excel files that vlookup the TM1 ID back to the Employee ID. It's convoluted, but it does the job.

Martin

Interesting approach.

How do you do the standard employee reporting? Or are you saying that you have a second employee cube which has only sensitive data in it and that is where you do the lookup?

How do you create the IDs to begin with? Just increment next available one or something?

[Martin Ryan]

How do you do the standard employee reporting? Or are you saying that you have a second employee cube which has only sensitive data in it and that is where you do the lookup?

There is only one cube, but in looking at the cube on its own you cannot tie the numbers back to a person. You must use the vlookup which is in the password protected Excel workbook to get the name.

On the reporting side, I can do it by consolidated level, or for a detail level the vlookup will have to exist in the Excel reporting spreadsheet to get meaningful names. In my particular situation I don't need to report by individual person, only enter data by individual person. I do need to report by individual title, but that is held as another dimension so the employee dim reference is "All Employees".

How do you create the IDs to begin with? Just increment next available one or something?

The database guys are taking care of that. I'm not sure how they're doing it. If it were me I'd apply an MD5 hash on the employee ID, or something like that.