TM1 Forum

Dear Sir

Hope to get some views and solutions to my queries as follows:

a) Am I able to add new dimension(s) to an existing cube? If yes how? If no, what is the best solution to add the new dimension? I think it's a bit troublesome to recreate a new cube
b) How can I block the individual user from accessing the certain element?
c) If there is a new release of data, for e.g. 2Q GDP 2008 and the embargo date is on 12 August, how can I block this data from all users to access except a few selected staff. Users are still able to access to all other data of the same element like 1Q 2008, 1Q 2007, 2Q 2007, 3Q 2007, 4Q 2007 and so on.

Thanks.

Regards
TKK

kiamkhai wrote: Hope to get some views and solutions to my queries as follows:
a) Am I able to add new dimension(s) to an existing cube? If yes how? If no, what is the best solution to add the new dimension? I think it's a bit troublesome to recreate a new cube
b) How can I block the individual user from accessing the certain element?
c) If there is a new release of data, for e.g. 2Q GDP 2008 and the embargo date is on 12 August, how can I block this data from all users to access except a few selected staff. Users are still able to access to all other data of the same element like 1Q 2008, 1Q 2007, 2Q 2007, 3Q 2007, 4Q 2007 and so on.

I think that your first port of call should be the Operations manual, in particular the chapter on security. It'll cover everything you need. But in summary:

(a) There is no way to add a new dimension to a cube. All you can do (assuming that you want the new cube to have the same name) is export the existing data into a text file, delete the cube, recreate it with the new dimensions, and re-import the data.
(That's unless you want to get tricky and rename the .cub file while the server's down, restart the server, create the cube using the old cube's original name, then use a cube view to pull the data from the old cube into the new one via TurboIntegrator. Unless you have gigabytes of data in the cube, however, the first option is probably the better one.)
(b) You need to create security groups and assign the users to one or more of them. You then need to right click on the dimension that contains the element that you want to restrict. Select the menu item Security -> Elements Security Assignments. This will allow you to set Read or Write permissions for each element for each user GROUP (not individual users). Set the permission to None for the security group which contains the users who you want to stop from seeing the element. Be aware that once you turn on this security, you have to remember to maintain it whenever you add new elements to the dimension.

Remember that TM1 uses the LEAST restrictive security model, so if you want to stop a user from seeing the data for an element they must not be in ANY groups which has access to that element.

(c) Use the same method as (b), but change the permission from None to Read (or Write) after the 12th of August.

Alan Kirk wrote: I think that your first port of call should be the Operations manual, in particular the chapter on security. It'll cover everything you need.

That'll learn me to rely on memory; it's actually the TM1 Developers' Guide, chapter 6.

kiamkhai wrote: I think it's a bit troublesome to recreate a new cube

Creating the new cube is not much bother. What is troublesome is that any and all reports that use the cube need to be updated, and it is especially troublesome if those reports are not under central control. What I have done in an environment with large numbers of user-created reports floating around is this:

1) Give the new cube a new, different name.
2) Populate both cubes in parallel during a transition period.
3) Notify the user community that they have 30 or 90 days to update their reports to use the new cube.
4) Pull the plug on the old cube after a final deadline warning,
... but be prepared to put it back temporarily if anybody important howls.

Regards,
Mike L

Mike L wrote:

kiamkhai wrote: I think it's a bit troublesome to recreate a new cube

Creating the new cube is not much bother. What is troublesome is that any and all reports that use the cube need to be updated, and it is especially troublesome if those reports are not under central control.

That's a very good point. Similarly, none of the views that were defined for the old cube (public AND private) will work with the new cube.

Generally speaking, building a cube should be considered a "one shot" deal. There will be occasions when you have no choice but to "rebuild", but if there ARE alot of predefined views and reports it can be more trouble than it's worth.