TM1 Forum

Does anyone know how to sort the Group Name in Cube / Dimension / Element security assignment window?
By default, TM1 order the groups randomly. So having a lot of groups might cause sore eyes since you have to look at the group name one by one.

So far I can only sort the Cube or Dimension or Element names, but not the groups

Have you tried veiwing the security cube itself? If you're not sure how to see this cube, enable control objects in server explorer.

First up its not random - they appear in element number order which is determined by the order in which they are added. Second, no. You can not sort that window across the top. Your only option is to use the control cube instead and edit it that way. That then gives you all the search / sort functionality of the cube browser and is normally how i edit mine.

I know it can be done from the security cubes, but it only works for element security and not for the cube security (I don't know about dimension security since I never messed it up, but I think it will behave the same way as cube security is).

When you grant a group access to a cube using Security Assignment menu, the system will automatically grants access to all of that cube's dimensions. But if you do this from the security cube, then that will only granted access to the cube but not to its dimensions. Therefore, the members of that group will be able to see the cube but unable to open it, with something like 'lack of access to dimension #1, #2, .... " error message.

For the element security, there's no problem assigning it using the security cube since it's already the lowest level and security inheritance need to be done.

I think IBM should either allow user to sort the groups, or sort it by name by default. After all, there's not much use ordering it by index (or by whatever it is).

comma wrote:I know it can be done from the security cubes, but it only works for element security and not for the cube security (I don't know about dimension security since I never messed it up, but I think it will behave the same way as cube security is).

Well first off, you don't sort a cube, you sort the dimensions via a subset then when you view the cube it will be sorted in the order you want. ALL the cubes in TM1, whether they be ones you create in your model, or control cubes, are just cubes. All the functionality applies to all cubes. If you want to see the groups in alphabetical order just create a subset of the }Groups dimension like this:

{TM1SORT( {TM1SUBSETALL( [}Groups] )}, ASC)}

The same holds true for any other control dimension.

comma wrote:When you grant a group access to a cube using Security Assignment menu, the system will automatically grants access to all of that cube's dimensions. But if you do this from the security cube, then that will only granted access to the cube but not to its dimensions.

Unless TM1 has changed it's behavior recently this is just not true. Cube security and Dimension security are separate entities. Granting access to a cube will not automatically grant access to all the dimensons in a cube UNLESS you don't have any security defined for your dimensons. You don't have to secure dimensions in TM1 if you don't want to. If you don't ever right click on the Dimensions object in TM1 and select Security Assignments then you won't have dimension security and thus no }DimensionSecurity cube. If you don't explicitly secure your dimensions then granting access to a cube is all you need to do for a user to see a cube. If you have secured your dimensions then you'll have to grant access there and then if you have secured any of the dimension elements individually you'll have to grant access there.

I almost never use the TM1 supplied security interfaces. I always just go directly into the contol cubes. This is because 1) I almost always use rules to help me with security and 2) I like to create views that filter and sort the dimensions in the way that I want.

tomok wrote:

comma wrote:When you grant a group access to a cube using Security Assignment menu, the system will automatically grants access to all of that cube's dimensions. But if you do this from the security cube, then that will only granted access to the cube but not to its dimensions.

Unless TM1 has changed it's behavior recently this is just not true. Cube security and Dimension security are separate entities. Granting access to a cube will not automatically grant access to all the dimensons in a cube UNLESS you don't have any security defined for your dimensons.

Actually Comma is correct, and I don't think that this is recent; I know that the behaviour is the same in 9.0. But just to illustrate on 9.5, I have two dimensions A Test Dim and B Test Dim assigned to A Test Cube

Initially neither one of them has any security access for any group: I assign Write security to the cube to group 10000 via the cube viewer: I assign Write access to group 10100 via the dialog: Look at the dimension security again and you can see that access was assigned to 10100 without me needing to do it explicitly, but not to 10000: When a user in 10000 goes to access the cube they'll get an error that they have no access to the dimensions. When a user in 10100 does they'll be fine. The two securities may be separate entities, but clearly there are some smarts built into the dialog that will automatically update the security access to the dimension.

tomok wrote:You don't have to secure dimensions in TM1 if you don't want to. If you don't ever right click on the Dimensions object in TM1 and select Security Assignments then you won't have dimension security and thus no }DimensionSecurity cube. If you don't explicitly secure your dimensions then granting access to a cube is all you need to do for a user to see a cube. If you have secured your dimensions then you'll have to grant access there and then if you have secured any of the dimension elements individually you'll have to grant access there.

I'm not sure that that's correct either. I haven't tested it because I don't have an unsecured session to hand but I believe that assigning security to a cube will also cause the dimension security cube to be created.

Alan Kirk wrote:I'm not sure that that's correct either. I haven't tested it because I don't have an unsecured session to hand but I believe that assigning security to a cube will also cause the dimension security cube to be created.

I just ran a quick test, creating a server instance from scratch and none of the security cubes get created unless you spefically right click on the folder header and choose Security Assignments first. That is the act that actually causes the cube to be created in TM1. When you first create any of these "Security" cubes the initial value, in every cell, is always WRITE and you have to change it to something else. If you add another cube, dimension, or element, all the security will be blank for that new object until you either 1) go through the security interface, or 2) add the value directly to the cube.

I've also tried what tomok said and it seems he's right.
Some conclusions that I can get:
1. }CubeSecurity, }DimensionSecurity, and }ElementSecurity_DimensionName control cubes are only created when we do security assignment for each of respective objects.
2. If the control cubes don't exist, the default access of that object (i.e. all cubes, dimensions, and elements) for all groups is WRITE.
3. Cube security assignment can be done from the }CubeSecurity cube IF the }DimensionSecurity doesn't exist. Because no }DimensionSecurity means all groups always have WRITE access to all dimensions. If }DimensionSecurity does exist then we still have to do security assignment for the dimensions, OR do the cube security assignment from TM1 user interface instead of from the control cube.

What happen in my case (and Alan too, perhaps) is someone has already done the Dimension Security Assigment at least once.

Now, the next thing to test is deleting the }DimensionSecurity control cube. Can I just shutdown the TM1 server and delete the }DimensionSecurity.cub? Will this, then, change the access of all dimensions for all groups to WRITE? I'll try this later, but it won't hurt if someone already has the information and share it.

Edit: just to add it up, what I said before:

comma wrote:When you grant a group access to a cube using Security Assignment menu, the system will automatically grants access to all of that cube's dimensions.

is true if the }DimensionSecurity control cube exists. Like Alan has proved

comma wrote:Now, the next thing to test is deleting the }DimensionSecurity control cube. Can I just shutdown the TM1 server and delete the }DimensionSecurity.cub? Will this, then, change the access of all dimensions for all groups to WRITE? I'll try this later, but it won't hurt if someone already has the information and share it.

It worked fine with the Planning Sample database; there were no issues with opening secured cubes after the cube was deleted while the server was down.

I've never needed to hide a dimension as they are all used in cubes that at least some users need to see. for that reason i've never had the }DimensionSecurity control cube so it's always defaulted to WRITE as stated. in fact WRITE is a confusing term to use in this case as to write to a dimension (ie. change elements in it) you need to have the admin license on your machine. seeing as those people are normally admin anyway, it really only needed to have the options of READ or NONE...

Steve Vincent wrote:I've never needed to hide a dimension as they are all used in cubes that at least some users need to see. for that reason i've never had the }DimensionSecurity control cube so it's always defaulted to WRITE as stated. in fact WRITE is a confusing term to use in this case as to write to a dimension (ie. change elements in it) you need to have the admin license on your machine. seeing as those people are normally admin anyway, it really only needed to have the options of READ or NONE...

I'll agree that the DimensionSecurity cube is not needed very often because if you need access to a cube then you need access to all the dimensions in it. Why would you need WRITE access to a cube and then READ to the dimensions. All this does, as we all know, is just make your access to the cube READ. However, there is one very good example where the DimensionSecurity cube is benificial. You can give ADMIN priviliges to a dimension with it, without having to make someone a full Admin. I have had numerous occassions where this was beneficial when there was a special dimension, like an Account dimension with a limited hierarchy, or something different, that you wanted the user to be able to maintain with an XDI worksheet. You can give them ADMIN access to the dimension and then they can maintain the hierarchy themselves and not have to be an ADMIN over anything else. That can be very useful.

I just finished a project where I did that very thing. I created an application folder called Dimension Worksheets and stored several XDI worksheets in there. You have to publish them as an XLS insted of XDI because TM1 get''s confused if it's not an Excel sheet. My user instructions were 1) open the sheet in TM1, 2) modify the sheet as desired, 3) do a Save As, naming the file "YourDimension.xdi", 3) do a Dimension Save in TM1, 4) Update the sheet in the Applications folder. Worked like a charm.

We had an issue like this. We just deleted the dimension security cube and restarted the server. After we did this it did (As you mentioned above) default back to write.

tomok wrote:

Steve Vincent wrote:I've never needed to hide a dimension as they are all used in cubes that at least some users need to see. for that reason i've never had the }DimensionSecurity control cube so it's always defaulted to WRITE as stated. in fact WRITE is a confusing term to use in this case as to write to a dimension (ie. change elements in it) you need to have the admin license on your machine. seeing as those people are normally admin anyway, it really only needed to have the options of READ or NONE...

I'll agree that the DimensionSecurity cube is not needed very often because if you need access to a cube then you need access to all the dimensions in it. Why would you need WRITE access to a cube and then READ to the dimensions. All this does, as we all know, is just make your access to the cube READ.

Actually we don't all know that. In fact, in the illustration provided earlier it may be noted that the smarts that are built in to the cube security dialog only feel the need to assign READ access to the dimensions, which would seem to be a bit pointless if doing so negated the write access to the cube itself.

Consider the following situation where two users have write access to a cube, but one has write access to its dimension and the other has only read access:
One might expect, if Read access to the dimensions meant Read access to the cube, that the ReadDimClient user would not be able to write a value into the cube and yet:
So what's the real difference between Read and Write for dimensions?

It's about access to the dimension itself, not the cubes that it appears in. Primarily it's in whether you can change the attributes. If you have Write access, you can make a change to the attributes of the dimension. (I'll spare you all the screenshots but WriteDimClient can change the Desc alias attribute in A Test Dim, ReadDimClient can't.)

I picked that one up a few years back with one of our costing models allowed users to assign descriptive names to quote number elements. I had to assign them Write access to the dimension to let them do so.

I've tried deleting the }DimensionSecurity and it worked. Just like everyone else have confirmed.
I think it would be nice to put this thread on the FAQ