New to TM1: Security in Dimensions Elements

[sandrak]

Hello, I am a little new with tm1

I have a cube with a 13,000 element dimension of products. I want to secure the elements for my groups, but is very slow and complex to choose who is able to see elements. I am able to write formulas on }elementsecurity cubes? I found on manuals that this option is available in cells level security, but I suppose this only applies to one cube.

I wrote a formula on this element cube dimension but my user saw the elements. If this is not a posible answer how does everybody handle this problem? with the element security window only?

Thanks

[Alan Kirk]

Hello, I am a little new with tm1

I have a cube with a 13,000 element dimension of products. I want to secure the elements for my groups, but is very slow and complex to choose who is able to see elements. I am able to write formulas on }elementsecurity cubes? I found on manuals that this option is available in cells level security, but I suppose this only applies to one cube.

I wrote a formula on this element cube dimension but my user saw the elements. If this is not a posible answer how does everybody handle this problem? with the element security window only?

Thanks

By "formulas" I presume that you mean "rules". I haven't done this myself but I've seen it referred to in the Forum in the past, so yes it should work. You may want to post the rules that you were using along with a description of your }Groups dimension; it may just be a syntax problem.

For a 13000 element dimension, I wouldn't attempt to maintain it through a GUI. We use a slice from the }ElementSecurity_product cube, though we do have SPF / Beachware which allows us to copy and paste the values for similar products into other products. Even without that tool, though, you could use DBS formulas for a similar effect.

Another option is to use a TI. For example, if you know that all of the products which are descendents of a particular consolidation need to be assigned to particular group(s) it's pretty easy to use the ElIsAnc function to create a TI to automatically update the }ElementSecurity_product cube.

(Edited to correct cube names.)

[TomBr]

Hi,

You can write security rules either on the dimension or the cube.

From your email, it seems you only need to write rules on the dimension. To write a rule on the dimension called Product you would write the rule on the cube
}ElementSecurity_Product
and this would apply to all cubes that use that dimension. For example if you had four products in the dimension A,B,C & D and you wanted to give the Group Test write access to A and read access to the rest, the rules would be :

SKIPCHECK;
['A','Test']=S:'WRITE';
['Test']=S:'READ';
FEEDERS;

Perhaps your issue is that there is a hierarchy in the dimension and you are not dealing with this in your rules - if you could post your rules it would be useful.

Also, it is worth selecting Security\Refresh Security to see if that sorts the issue.

For the record, Cell level security applies to only one cube and it is means you can write security rules affecting more than one dimension in that cube. Suppose for example you had payroll data by individual in the cube. You could write a cell level security rule that might say users can can only see the salaries for the department but not for individuals in the department. You could not achieve this affect by writing rules on the }ElementSecurity_Product and }ElementSecurity_Department cubes.

Hope this helps,

Tom

[John Hobson]

I recently dealt with this is a product dimension by automating the cascade of security rights from a specified level downwards, so as to avoid having to set the rights manually.

here's how to do it.

1. Set up a flat file to create the product dim

This file has the hierarchy in each row (e.g. Company, Dept, Category, Sub Category etc)
Each row also contains

• UserId(s) of as many people as may be people associated with it (we had up to 3)
  
  The top product associated with each base level product from a security perspective (e,g. men's socks might have Menswear as their top product if this were the scope of security access for the person(s) associated with the product.)
  
  The security group name to which the people should belong (e.g. Menswear Buyers)

2. Add a text attribute TopProduct to the Product dimension

3. Write a TI process so that when processed this flat file:

• Creates / Updates the dimension
  Adds the User IDs to the Security groups
  Sets an attribute value for each N Level product in the "TopProduct" attribute using the top product specified

3. Write a rule in the }ElementSecurity_Product cube

Code: Select all

[]= S:
if(elisanc('Product', attrs('}Groups', !}Groups, 'TopProduct'), !Product)=1 %
(dimnm('Product', dimix('Product', attrs('}Groups', !}Groups, 'TopProduct'))
@= !Product),
'WRITE', STET);

This totally automates the cascade of security down from the top product. Of course you can't then edit by exception.

If you wanted/needed to do that you could use the same principles but populate the security cube using a TI rather than a rule.

Hope this helps

John

[Eric]

Don't forget you will need to add

FeedStrings;
http://tm1-tipz.blogspot.com/2007/12/fe ... tring.html

to the first line of your rules for security cubes.

Also check your config file for

AllowSeparateNandCRules=T
http://tm1-tipz.blogspot.com/2008/01/fe ... ow-up.html

If you don't you can have both of these you can have some inconsistencies.

[John Hobson]

Don't forget you will need to add

FeedStrings;
http://tm1-tipz.blogspot.com/2007/12/fe ... tring.html

Good point but don't assume that we all use feeders!

In small dense cubes the extra hassle just ain't worth it IMHO.

[David Usherwood]

Once again I'm going to challenge the use of FEEDSTRINGS in most (not all) cases.

Feeders do two jobs:

a Tell TM1 that values should be consolidated;
b Tell TM1 not to zero suppress a calculated value.

For strings, a is irrelevant. b may be convenient, but I can't see its relevance to a security cube, which users don't see anyway.

Somebody tell me I'm wrong (go on now), but to me, it doesn't stack up.

[Steve Rowe]

I'd agree with David, the security values are for internal use by TM1 and so feeding them is not important and wont change the performance of the system. In fact it probably makes it worse as there must be some overhead to firing feeders. The only real use is if you wanted to zero-suppress the cube so that you could review the values.

Cheers,

[getasim]

Where will i find the cube called }elementsecurity_ ? I have control objects "on" but dont see any cube called }elementsecurity

Thanks

[David Usherwood]

That was quite an interval for a response - July to December . Anyway...

The security cubes are created when you put some security on the dimension. So right click on the dimension, assign some security to something, then turn control cubes on - the security cube will show up.

HTH

[getasim]

I know Just joined this forum. Thanks for the reply. I got it. One problem i encountered is that the elements of the dimension are not sorted when you open the dimension element security GUI. Any reason or solution to this problem?

Thanks

[Alan Kirk]

One problem i encountered is that the elements of the dimension are not sorted when you open the dimension element security GUI. Any reason or solution to this problem?

They ARE sorted... they're just sorted in dimension index order. In other words, it's the same order that you'll see when ytou click the "All Elements" button in the subset editor.

You can't do anything about that in the GUI dialog, but what you CAN do if you want is create a view in the relevant }ElementSecurity_ cube and make your changes in there. That allows you all the usual sorting options for the dimension.

[paulsimon]

Hi

When it comes to sorting dimension, I have found that the best approach is to ignore the TI Function DimensionSortOrder, and to instead put the entries directly in to the }DimensionProperties Cube. There are elements there

SORTCOMPONENTSSENSE
SORTELEMENTSSENSE
SORTCOMPONENTSTYPE
SORTELEMENTSTYPE

which do the same job as the parameters of the DimensionSortOrder TI function. The advantage is that this works whether you update the dimension by TI or the Dimension Editor.

Regards

Paul Simon

[Eric]

Also right click the dimension... there is an option set element order...

[Mike Cowie]

Also right click the dimension... there is an option set element order...

That works to a large extent, but one thing I reported in a Cognos inquiry not that long ago is that you actually can't set every possible dimension element sort option using this "Set Elements Order..." UI. For example, if you wanted to sort by hierarchy, but also have elements within rollups in that hierarchy (Components) sorted alphabetically, you can't do it with that little window. Pretty stupid interface omission, but you can use Paul's suggestion or the TI dimension sort function to get around that.

One note on Paul's suggestion of editing the }DimensionProperties cube: in the past I've had to re-save the dimension in order for those manual changes to sort settings to take effect. Other than that, it works really well.

Regards,
Mike

[paulsimon]

Hi

For the cascading security you may like to try the following alternative.

My example uses Electricity Generating Stations, rather than Clothing Products, but the key thing is that a hierarchy is involved.

Create a cube called zStations_Security_Cascade with dimensions
Station
}Groups (You can use } control dims in normal cubes)
zStations_Security_Cascade_Meas
which has two string elements:
Input
Result

Create a Rule and add the following:

skipcheck ;

['Result']=S:
IF( DB('zStation_Security_Cascade',!Station,!}Groups,'Input') @<> ''
,
DB('zStation_Security_Cascade',!Station,!}Groups,'Input')
,
DB('zStation_Security_Cascade',
elpar('Station',!Station,1),
!}Groups,
'Result'
)
) ;

This is a recursive rule, which cascades any value entered in to the Input measure down to all elements below it, until interrupted by another Input Measure. See the attached example.

Set the security on this cube so that only Admins & Security Admins can see it.

Then in the }ElementSecurity_Station cube you just need to add the following rule:

skipcheck ;

[]=S:DB('zStation_Security_Cascade',!Station,!}Groups,'Result');

This pulls the Results of the cascaded security across, to the security cube where it has the desired effect.

The only thing that you need to remember is that TM1 can be a little finicky around Rules in security cubes, and you may need to run a TI process with the SecurityRefresh function to get TM1 to acknowledge changes in security. However, I generally find that this isn't necessary. In the worst case, it is only needed when you actually change the security. I would be interested to hear how it performs on a 13000 element dimension. The dimension where I am contracting has around a 1000 elements.

Things do get a little more complex if you have alternate hierarchies in your dimension, ie if an element can have more than one parent. However, I have successfully extended the above approach to cope with dimensions that have 6 altenate parents for some elements.

Regards

Paul Simon

[paulsimon]

Mike

Yes - thanks for pointing that out - the dimension sort order cube options in }DimensionProperties only take effect when you edit and re-save the dimension. You may need to get TM1 to realise that the dimension has been edited, for example, inserting a dummy element and then deleting it. I think if you don't make any changes then TM1 does not bother to save the dimension.

When you think about it is logical that TM1 only changes the sort order when you save the dimension, since you are actually changing the physical order of the dimension, and it can only do that when the dimension is saved.

One other note on the TI DimensionSortOrder function is that it is much worse, in that it only applies the sort order, when the dimension is completely rebuilt, and most TM1ers I know prefer to just delete consolidations.

Regards

Paul Simon

[Eric]

you actually can't set every possible dimension element sort option using this "Set Elements Order..." UI. - MC

Thanks, I didn't know the other options were available!

[getasim]

Paul,
Thanks for the detailed explanation with the screen shots. This is awesome

[Steve Vincent]

Hi

When it comes to sorting dimension, I have found that the best approach is to ignore the TI Function DimensionSortOrder, and to instead put the entries directly in to the }DimensionProperties Cube. There are elements there

SORTCOMPONENTSSENSE
SORTELEMENTSSENSE
SORTCOMPONENTSTYPE
SORTELEMENTSTYPE

which do the same job as the parameters of the DimensionSortOrder TI function. The advantage is that this works whether you update the dimension by TI or the Dimension Editor.

Regards

Paul Simon

Of course it'd be too much for anyone to bother putting details of that in the documentation tho, wouldn't it?

What are the criteria for those fields, i've never used them before but sounds like they might solve me one or two niggling issues with some of our hierarchies.