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
TM1 process security
-
- MVP
- Posts: 3113
- Joined: Mon Dec 29, 2008 6:26 pm
- OLAP Product: TM1, Jedox
- Version: PAL 2.0.9.18
- Excel Version: Microsoft 365
- Location: Brussels, Belgium
- Contact:
TM1 process security
Best regards,
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
Wim Gielis
IBM Champion 2024
Excel Most Valuable Professional, 2011-2014
https://www.wimgielis.com ==> 121 TM1 articles and a lot of custom code
Newest blog article: Deleting elements quickly
-
- MVP
- Posts: 195
- Joined: Wed Jul 22, 2009 10:35 pm
- OLAP Product: TM1
- Version: 9.5.2 FP3
- Excel Version: 2010
Re: TM1 process security
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
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