Access tables based on elist in TM1

[jviegas@bi4all.pt]

Hello to all,

My question is if its possible to show/hide a cube based on the node selected to enter a model.

In Cognos planning it would be a simple access table with elist.

Can anyone help me on this ?

Thank you,

Jorge

[David Usherwood]

If you are using 'regular' TM1, assign your users to groups, then select the dimension you wish to use as your 'elist', select Security\Elements Security Assignments and assign the access you require to the groups.

If you are using Contributor and Performance Modeller, you set up access when you create an application. It's not nice because PM requires a group per 'elist' - but you do it in the frontend.

[jviegas@bi4all.pt]

If you are using 'regular' TM1, assign your users to groups, then select the dimension you wish to use as your 'elist', select Security\Elements Security Assignments and assign the access you require to the groups.

If you are using Contributor and Performance Modeller, you set up access when you create an application. It's not nice because PM requires a group per 'elist' - but you do it in the frontend.

David,

I don't seem to understand, sorry.

Let me take an example:

I have (for example) 5 users (in this case its not relevant)

the hierarchy (known in planning as elist) is for example:

TOTAL
A
B
C
(in this model the hierarchy has around 222 items)

and I have 3 cubes (AA, BB, CC)

I want the bahaviour:

When I enter the hierarchy in A I want to only see cube AA
if I enter in B only see BB
and in the case of C I would only see CC

I really don't know if this is possible although in planning this if easily done.

[David Usherwood]

If you have split your data by cubes then you assign users to groups, as before, then rightclick on the 'Cubes' in Perspectives and select Security Assignments.

[kugors]

Jorge,

I have just finished "migration" my client from Planning to TM1, and know what you want to achieve. The answer is simple - you can't do it. In Planning you could show different data (cubes, elements, views) in different nodes. In TM1 you apply security to cubes, dimensions and elements of dimension to user groups. So, if certain user, have access to all of the cubes, he will always see this cubes, no matter which node he choose. Switching nodes, affect only access to elements in dimension with approval hierarchy.

[David Usherwood]

Well....
You can't show different views to different users, but
If you put the secured dimension on the page, users will be able to select the elements which they can access.
Doesn't sound that unworkable to me.

[kugors]

I don't think that is what he wants to achieve.

I want the bahaviour:

When I enter the hierarchy in A I want to only see cube AA
if I enter in B only see BB
and in the case of C I would only see CC

In my case, users had functionality, that when they entering different nodes, they had different views, access to different cubes, different access to elements of dimension (other then this with nodes) and this was set on node. I think, you can't set this in TM1. If you will tell me how to set, that one user will see different cubes while selecting a different node in application, I will politely apologize and give you many thanks

[declanr]

I don't think that is what he wants to achieve.

I want the bahaviour:

When I enter the hierarchy in A I want to only see cube AA
if I enter in B only see BB
and in the case of C I would only see CC

In my case, users had functionality, that when they entering different nodes, they had different views, access to different cubes, different access to elements of dimension (other then this with nodes) and this was set on node. I think, you can't set this in TM1. If you will tell me how to set, that one user will see different cubes while selecting a different node in application, I will politely apologize and give you many thanks

Assign each user to a security group that is the same as their client name e.g. client john.smith belongs to group john.smith in addition to all users belonging to a secondary generic group.

The generic group allows very minimal access for the user to have access to a 2d cube made up of the client dimension and a string dimension... in this they can use a picklist to select what you are referring to as your "node".

Apply rules to the security cubes that then updates what that user can see based on what they have selected in the 2d cube. You will need to run a security refresh after they change their selection in the 2d cube but that is simply done if the 2d cube is through the web and stick an action button in their with it.

[kugors]

I don't think that is what he wants to achieve.

I want the bahaviour:

When I enter the hierarchy in A I want to only see cube AA
if I enter in B only see BB
and in the case of C I would only see CC

In my case, users had functionality, that when they entering different nodes, they had different views, access to different cubes, different access to elements of dimension (other then this with nodes) and this was set on node. I think, you can't set this in TM1. If you will tell me how to set, that one user will see different cubes while selecting a different node in application, I will politely apologize and give you many thanks

Assign each user to a security group that is the same as their client name e.g. client john.smith belongs to group john.smith in addition to all users belonging to a secondary generic group.

The generic group allows very minimal access for the user to have access to a 2d cube made up of the client dimension and a string dimension... in this they can use a picklist to select what you are referring to as your "node".

Apply rules to the security cubes that then updates what that user can see based on what they have selected in the 2d cube. You will need to run a security refresh after they change their selection in the 2d cube but that is simply done if the 2d cube is through the web and stick an action button in their with it.

OK. I apologize, this is doable, but I think it will be hard to administrate. I must gain more experience to judge, that something is doable or not.

One question

... and stick an action button in their with it.

This means that there is a way to place action button in TM1 WEB Application (contributor)?

[jviegas@bi4all.pt]

Hello,

Thanks for the feedback.

I've been checking possibilities and I'm close to say this is not doable.

In my case I'll use less than 3 users a the filter is the cubes depende to the hierarchy dimension/node.

I can filter this information with the client groups but if a client uses two nodes with diferent configurations, the cubes are merged showing both whatever node is selected.

Best Regards,

Jorge

[declanr]

This means that there is a way to place action button in TM1 WEB Application (contributor)?

Sorry Kugors, as "Contributor" had never actually been mentioned I was just referring to TM1 in general. I personally find contributor (even in its shiny v10 appearance) quite restrictive and it is very easy to build a custom workflow that gives you all the same Contributor functionality whilst allowing you to do the extra stuff I have mentioned earlier - that as you've pointed out; Contributor just can't do.... add in the use of a bit of wingdings within a websheet and some conditional formatting you can have a very attractive looking workflow administration page.

All the benefits - none of the weaknesses... however it does require the developer to really get into the "body of TM1" which can be quite daunting for someone who is only experienced in Cognos Planning and doing their first TM1 job.

[mce]

I think this is another example of why we should not always look at TM1 from a Cognos Planning perspective. Both tools have their great advantages and strengths. Rather than doing development in TM1 for a model that is designed for Cognos Planning, I think we should re-design the model from a TM1 perspective based on business requirements if we want to achieve a proper TM1 application. That is what I have been doing for ex-Cognos Planning models. After spending 6 years in building models in Cognos Planning, for the last over 3 years I have been building models in TM1. If you approach TM1 from a Cognos Planning perspective, you may see some difficulties and disadvantages with respect to Cognos Planning. If you consider your business requirements from a TM1 perspective, you will see a lot of additional capabilities in your hands in delivering those requirements with TM1.

With the new Performance Modeller, it looks new TM1 modellers are being encouraged to use TM1 from a Cognos Planning perspective, and I doubt if this is the right way to go for TM1.

[Steve Rowe]

Hear hear mce,
I'm sounding like a broken record at work at the moment "give me the requirements not a technical spec of what you think you want me to build". That applies to us devs too when moving between tools, you need to start from the business requirements and not confuse these with the way they were met in another application.
Cheers,