Page 1 of 1

Is Composite Element locking facility available.

Posted: Wed May 09, 2012 6:47 am
by ryan
Dear All,

#1
In our organisation, currently we are locking the data by using one element (especially period dimension's element).

If composite Element locking facility is possible/available in TM1, I appreciate if some one could help me.

Let say if there are 3 versions for a given period (eg: Actual, Forecast1, Forecast2 for 201204). Right now we are locking 201204 element, hence all the 3 versions are getting locked.
I want to lock 201204's Forecast1, hence 201204's Actual and Forecast2 are available for editing/entering.

#2
Are there any control objects thru which I can see the locking information?

Thanks in advance.

Re: Is Composite Element locking facility available.

Posted: Wed May 09, 2012 7:04 am
by Gregor Koch
Hi
Do a search on "Cell Security". There are plenty of posts in this forum and it is also in the standard documentation.
Cheers

Re: Is Composite Element locking facility available.

Posted: Wed May 09, 2012 6:09 pm
by jim wood
This gets a bit sticky but you can achieve something like this be creating multiple groups and moving users in and out of the groups to achieve what you are looking for. This is more difficult than standard security. While Gregor is right there are posts on here about the very same subject (Do a search you'll find some good stuff.) there is nothing about this in the standard documentation,

Jim.

Re: Is Composite Element locking facility available.

Posted: Wed May 09, 2012 11:57 pm
by Gregor Koch
Maybe my wording wasn't clear and properly too short. But, and unless I misunderstood what is needed, Cell Security is what I think is the easier approach in this case and it (or how to set up Cell Security) is documented in the standard documentation.

Re: Is Composite Element locking facility available.

Posted: Thu May 10, 2012 12:48 am
by ryan
Gregor Koch wrote:Maybe my wording wasn't clear and properly too short. But, and unless I misunderstood what is needed, Cell Security is what I think is the easier approach in this case and it (or how to set up Cell Security) is documented in the standard documentation.
I have created cell security cube for the required cube (let say ForecastCube). I can see }CellSecurity_ForecastCube in the server explorer.

I have included a rule in }CellSecurity_ForecastCube as below:

Code: Select all

['Forecast1','201204'] = S: 'LOCK';


To my surprise I can see locking applied to }CellSecurity_ForecastCube rather than ForecastCube.

Am I missing anything?

P.S: No SKIPCHECK; FEEDSTRINGS; statements included.

Re: Is Composite Element locking facility available.

Posted: Thu May 10, 2012 2:04 am
by Gregor Koch
ryan wrote: I have created cell security cube for the required cube (let say ForecastCube). I can see }CellSecurity_ForecastCube in the server explorer.

I have included a rule in }CellSecurity_ForecastCube as below:

Code: Select all

['Forecast1','201204'] = S: 'LOCK';


To my surprise I can see locking applied to }CellSecurity_ForecastCube rather than ForecastCube.

Am I missing anything?

P.S: No SKIPCHECK; FEEDSTRINGS; statements included.
Hi
Not too sure what you been by the locking is applied to the }CellSecurity_ForecastCube because you seem to be doing the right things.
If you write a rule in the }CellSecurity_ForecastCube this will define the cell security for the ForecastCube.
You'll notice that the }CellSecurity_ForecastCube is an exact copy of the ForecastCube including the }groups dimension.

A few pointers:
1. I would use 'READ' rather than 'LOCK'. On the different levels of security check this
http://publib.boulder.ibm.com/infocente ... _Grps.html

2. In your situation I would create an additional cube that has your Version, Period (and }groups) which you can use to flag which combinations should be READ, WRITE etc. so you don't have to hard code the rule. Obviously hard coding it wouldn't be very flexible. That way you could write your rule in the }CellSecurity_ForecastCube like so

[]=S: IF(DB('Lookupcube', !Version, !Period)@='W', 'WRITE', 'READ');

This is very simplified and the [] should always be handled with care. Personally I'd prefer a Lookupcube that has 1s and 0s but for that you will have to create a copy of the }groups dimension with N elements ... let's not complicate things.

3. You can find some discussions on why to use the SkipCheck; and Feeders; statements in this forum. Personally I would put the statements in but not feed at all. And unless you feel really comfortable with feeders the PrivilegeGenerationOptimization (found in standard documentation) configuration setting is not really an option for you.

4. Be aware that if there is no cell security on a cube other existing security e.g. the element security you have set will 'kick in'.

Hope this helps.