TM1 Forum

Hello everyone,

I used to develop this kind of solution in EP and I'm trying to find something that hides a cube view from elements of the Approval Hierarchy.

For example: I have an Approval Hierarchy as follows:

Title
--Contribution 1
--Contribution 2

This Cotnributor Application have 5 cubes: Cube 1, Cube 2...

In the element "Contribution 1" I have a group of users associated loading some kind of data but this users should only be able to see and input in the first 3 Cube Views.

The same for the group of users associated to "Contribution 2" but for the last 2 cube views (Cube 4 and Cube 5).

I need to find a way to separate the users without creating another application, to have the closest to the same result as possible in EP.

Can anyone help me?

Here is a list of things that are NOT going to work (I've tried already):

Using subsets of the Approval Hierarchy when creating the cube views for the Contributor Application.
ElementSecurity functions and configurations
CellSecurity functions and configurations

Thanks for your time.

Welcome to the forum.

You can't assign security to views apart from Public (everyone can see) or Private (only the user who created it can see). Views are merely windows into the cube.

Sounds to me like you need two things. The first is element security to control who can see which Contributor nodes. The second is cube security.

From the problem you've described group one ("C1") will need write access to the element "Contribution 1" and write access to cubes 1-3. They'll need either "read" or "none" access to "Contribution 2" and cubes 4-5.

The second group will need write access to "Contribution 2" and write access to cubes 4-5. They'll need either "read" or "none" access to "Contribution 1" and cubes 1-3.

Note that the lowest level applies, so if the user has write access to "Contribution 1" but only "read" access to cube 4 then the user will only have read access to Contribution 1 in cube 4. Similarly if the user has write access to the cube but read only access to one of the elements then they will still only be able to read.

One further point. If a single user belongs to two groups then they will get the highest level of permissions. So if a user belongs to both "C1" and "C2" then they will be able to write to both nodes in all cubes. E.g. as a C1 user they can write to Cube1 and as a C2 user they can write to "Contributor 2", thus they can write to that node in that cube.

HTH,
Martin

Hello Martin,

Thanks for your help, I think it's probably what we are going to do, if not, something like it.

If there is no way to "show" some cubes in one node and hide them in another as the users don't need to see them there are some clients that maybe won't change their applications from EP to TM1.

See you at the forums.

usagimd wrote: If there is no way to "show" some cubes in one node and hide them in another as the users don't need to see them there are some clients that maybe won't change their applications from EP to TM1.

You may well be right about people not changing from EP to TM1. I know I would be loathe to leave TM1 so I'm sure people who know EP well feel the same way. I know a lot of people are still using Adaytum because it's a lot of work to change. Not only the application, but the new methods it brings up.

In response to your specific point, to choose your node first and then choose your cube based on that node is quite a procedural way of doing things, rather than an OLAP way of doing things. If that's how you do things in EP then the only way I can think of replicating that in TM1 is via a VBA heavy Excel spreadsheet that's linked to TM1.

The more usual way of handling this in TM1 is as I've already outlined - give the user rights so they see some cubes for a given node but not others. (Give write access to the node and write access only to the cubes you want them to access). I may have confused the issue by giving you more information that you asked for, in pointing out that users who belong to two overlapping groups can end up with write access to areas that you didn't intend.

I note that you've said that cell security doesn't work, but it will work for the problem you outline (not necessarily in the way you want to do it though) and can get around the overlapping groups problem. It's just a pain to create and maintain so it's worth avoiding where possible.

When it comes to the bigger picture though, it depends on what's more important to you - the result or the way the result is delivered. You may well be right that a new method can be too much to thrust onto users who are used to their way of doing things.

Martin

"The more usual way of handling this in TM1 is as I've already outlined - give the user rights so they see some cubes for a given node but not others. (Give write access to the node and write access only to the cubes you want them to access)."

I gave access over "}ElementSecurity_DIM_HIERARCY" for the required nodes by Group
I gave access over "}CubeSecurity" for the required cubes by Group


But still I am viewing all the five cubes in the contributor.

Please suggest...