Managing Security with Rules

[hbell]

Are there any documentation sources for using cube rules to manage security in TM1? I have found only one, rather coy reference in the User Guide. That refers one on to the Operations Guide - which as far as I could see contained nothing on the issue.

I have experimented and found some curious behaviours: setting element level security with rules still seems to require that I open the "official" security maintenance screen and press "OK" for the rules to take effect. It seems that, just because the rules are reflected in the "}ElementSecurity" table does not mean that they will be in effect. The "WRITE" and "READ" values which you set in the rules also seemed to be case-sensitive.

Any sources on this would be much appreciated.

Is there anyway to be able to collapse Groups so that setting user access is less like looking for a needle in a haystack? For obvious if annoying reasons I'm unable to open the dimension with the dimension editor in order to create pseudo-parents.

many thanks ..........hugh

[John Hobson]

"still seems to require that I open the "official" security maintenance screen and press "OK" for the rules to take effect."

Just a quick thought on my way out...

If you change any security assignments and are not using the "official" UI then you probably need to do a "securityrfresh" (or is it "refreshsecurity") via a TI routine.

[ScottW]

Are there any documentation sources for using cube rules to manage security in TM1?
...
Is there anyway to be able to collapse Groups so that setting user access is less like looking for a needle in a haystack?

Rules are a great tool for maintaining security, the light coverage in the developers' and operations guides are probably because rules are generally a little tricky for novice TM1ers (even, or perhaps especially people who have extensive RDBMS experience) to get their heads around. I think that's a pretty weak excuse as to the lack of coverage but it partly understandable.

As already pointed out if you are using rules (or some other method such as entering in a cube view, or slice worksheet or websheet) you don't need to go into the security dialog and hit OK, you can also right click the server and do a security refresh or you can call the programmatic equivalent from a TI process.

TM1's security dialogs can be a real pain. Because there is no effective filtering as you point out and also the grid tends to go "wonky" and not line up with field headings so yo have no way of knowing which group is being assigned security. Also in models with large numbers of groups/clients/cubes/dimensions the security dialogs can take a very very long time to load or not at all. Therefore many experienced developers tend not to use this UI at al, ... at least there are workarounds.

The workaround for your desire to filter }Groups is an easy one provided you are comfortable browsing the security cube rather than the security UI. Create one or several attributes in the }Groups dimension and assign values either with data entry or via rule. You can then create dynamic subsets in the dimension to filter to the specific groups in question. Then browse the security cube and easily filter.

For easy access to security cube views you can drag any views you create into application folders, then they will be accessible at all times without having to view control objects.

[David Usherwood]

You may know this, but you haven't mentioned it.
Turn Control cubes on, then you can use the standard cube viewer to manage the various security cubes. Note that element security cubes are created when you maintain security against an element using the frontend - and you probably then need to refresh available servers and/or log out and back to see the cube.
If you are maintaining security manually, zero suppress can be very helpful. If you are using rules, you could consider Feedstrings, though I don't use it myself.
It would be interesting to fold in some nesting of security groups using secondary structures. I doubt it will go that way in the core product as it could break the flexibility and power of the present approach ie users are in (1 or more) groups, groups do the rest.
You could also consider slicing }ClientGroups out to Excel and filtering it, plus (perhaps) doing some VBA to control what is input to a cell (OnDoubleClick).
As John mentions, depending on what you do, you are likely to need to refresh security, either via the menu or via TI. I must admit I haven't found this to be a massive overhead, but other forumers definitely have. Not sure what the difference is.
(Update - ScottW's idea of attributes on }Groups is a very good one.)
HTH

[hbell]

..... thanks. Really useful ideas. I particularly like the Dynamic Subset views and have found them very easy to work with. One further question though ... I just added a new Group in the }Groups dimension. I set the Attribute so that it should show up in my view. However, it is not showing up. When I manually execute the filter again it does show up. It seems that the dynamic subset was not so dynamic - even though I can see that the expression is there .....

[Steve Vincent]

not sure what you mean, is it you have a cube view that uses dynamic subsets that aren't updating or something else? what do you mean by "manually execute the feeder"? posting the mdx code that the filter is using will help too, it might be somethign simple it's missing...

[ScottW]

If you have the view already open the new elements in the dynamic subset won't automatically come into the subsets on the row or column dimensions, this is normal. You have to refresh/rebuild/reopen the view for any new members of dynamic subsets to display.

[paulsimon]

Hugh

A couple of points on Dynamic subsets. I haven't tried this with a cube view, but we had a similar issue with a dynamic subset not refreshing in an Excel sheet (we were using it to derive a list of accessible centres. We had a dynamic subset listing all centres, and then relied on security to filter that list for the user that was logged on. We found that we had to run the M_CLEAR TM1 Macro to force Excel to update the subset. That may work for you too.

My guess is that what you would really like to do would be to define hierarchies of groups and to have security cascade down those?

It is not a good idea to define hierarchies in the }Groups dimension since this is a system maintained dimension. However, I use one of my library of TI functions to copy the }Groups dimension to a standard dimension zTDA_Control_Groups. I then add the hierarchies there. I then use this dimension in a 3 dimensional cube, and add some rules that allow me to cascade security down. In our case the security cascades down the centre dimension rather than the groups, however, I don't see why the same technique would not work for groups. In our case, we can say that if group X has access to consolidated centre C then they also get access to all the Centres below C. The 3rd dimension is just an input and result, whereby the result is the cascaded down security unless a different setting is entered in the input, in which case that is copied to the result and cascaded down. We then rule the Result back in to the security cube, where it has the desired effect. Obviously you need to set the security on the 3d cube to ensure that only people who should be able to access it can.

The only gotcha with rules in security cubes (and this is true whether you use an external cube or not) is the need to run a TI process with SecurityRefresh when a new element is added. However, this is not too bad if you can add it to the end of an overnight run.

Entering a security dialog box effectively does the same thing, but the TI command allows it to be scheduled overnight.

I hope things are going well in Burgess Hill. I am working with one of your ex-colleagues at the moment.

Regards


Paul Simon

[hbell]

... thanks to Steve for enforcing the discipline on me of posting the MDX code. As I pasted it I noticed the absence of a "TM1SubsetAll" statement That would certainly explain why nothing new got added to my attribute-based filter. Sorry - it's been some time (and a major upgrade) since I was hands-on with TM1. Some of this stuff is fairly new to me. Thanks for the additional replies. Paul: good to be back in a forum community with you after all this time.......hugh

[Steve Vincent]

You're in good company Hugh, there has been many times i've started to write a new thread, copied in some code and gone "Doh!" as i realised the error. Sometimes it takes that or someone else to have a quick look and ask "obvious" questions to be able to see the error.