TM1 Forum

Hello friends

(TM1 10.1.1)

Long post, but please stick with me Can anyone enlighten me on how process security works? I have been dealing with it today, and some of the observations seem bizarre.
The user I tested with, is not a member of the Admin group. He has only 1 group association (it's a pet model, there's only 1 non-admin group and a handful of clients).
Inputs in the }ProcessSecurity cube are done manually, no rules involved. I also did not use the interface to set the rights.

For example, I have 4 different processes:
*) process 1:
}ProcessSecurity cube entry: WRITE
Interface: Read
Does the Edit option shows when right-clicking the process in the Server Explorer: No
Can the security group save the process in the Server Explorer? No

*) process 2:
}ProcessSecurity cube entry: WRITE
Interface: Write
Does the Edit option shows when right-clicking the process in the Server Explorer: Yes
Can the security group save the process in the Server Explorer? Yes

*) process 3:
}ProcessSecurity cube entry: READ
Interface: Read
Does the Edit option shows when right-clicking the process in the Server Explorer: No
Can the security group save the process in the Server Explorer? No

*) process 4:
}ProcessSecurity cube entry: READ
Interface: Read
Does the Edit option shows when right-clicking the process in the Server Explorer: Yes
Can the security group save the process in the Server Explorer? No


My findings:

- I would say that process 3 is completely normal behaviour
- Process 1 and 2: I did not know that process security can be WRITE... In the user interface, Write cannot be set as privilege !
- Process 1: how can the internal security cube }ProcessSecurity and the user interface be different?
- Process 4: while not being able to save changes is to be expected, why is the Edit option upon a right-click of the mouse allowed?

This all holds after restarting the TM1 service.

Are these bugs/shortcomings, or should one just not use the internal security cube }ProcessSecurity to set the rights?
Because if I use the user interface and set everything to Read, saving the processes is not possible anymore, but some TI's have "Edit" greyed out and others not. Why the difference?

1 last important remark, which is against my understanding since when I started working with TM1.
I thought that TI processes are executed with admin privileges: I mean, whenever a group has Read access to a TI process, the group can execute the process successfully.
Even if the process writes data to a cube to which the group has no or limited rights.
This IBM technote supports that view: http://www-01.ibm.com/support/docview.w ... wg21459638
But then, use the CellPutProportionalSpread function in TI... the non-admin user executing this process should have the element security level of Write in order for the process to complete successfully. Go figure.

Thanks.

Wim

Wim,

I would treat it as bugs.

I just wanted to share that it seems like there was some bigger mess with setting security privileges in version 10.1.1 (HF5 in my case).

What I experience, I cannot rely anymore on changing assignment of users to groups by doing manual inputs in }ClientGroups cube.
I never had such problems in any other TM1 versions I was using. It always worked nicely and was very comfortable.

The only reliable way to do it is to use AssignClientToGroup TI function.

That is why I am not that surprised about what you described, this seems like a serious issue though.

My questions:
1. Does it start to behave better if you set Process Security using ElementSecurityPut TI function?
2. Are you still on 10.1.1 (HF?) or maybe it is already 10.1.1 FP1?

Regards