non-admins edit permission to 1 dimension via PAW ?

[tsw]

I'm having trouble giving edit permission on one single dimension thru Planning Analytics Workspace .

The non-admin user is ABLE to edit the dimension via Architect, but gets an insufficient rights to update dimension error via PAW.

Has anyone come across this requirement and was able to configure security so that editing works via PAW ?

Thanks!

Update: IBM has acknowledged this is a bug in latest versions of PAW. Thanks to all for help!

[declanr]

The user probably has Analyst permissions in Workspace. To gain access to the modelling capabilities they need to be set up as a modeler or admin (workspace groups not tm1 groups.)

[Steve Rowe]

You need to watch out for licencing too, editing of a dimension requires an admin licence irrespective of if they are "full admin" or not.... (in my opinion...)

[paulsimon]

Hi

We provide the ability for users to update dimensions, but not directly. In my view it is easy enough for an experienced developer to make a mistake using the Dimension Editor, let alone an end-user.

In our situation we have many contributors with their own local chart of accounts. They need to be able to update that and provide a mapping to the central chart of accounts.

We provide a cube view where they can type in the details of the base level elements, with mappings, and another where they can specify additional hierarchy in Child-Parent format. This can either be directly typed in to the Cube View or uploaded from CSV.

Once they have done that, they have an Action Button to run a process to take that information and update the dimension and attributes.

Users only have access to update the cube views related to their local chart of accounts and not those of other contributors.

The TI process runs as admin and therefore they do not need explicit rights to edit the dimension, only rights to run the process, The process includes a check to ensure that it cannot be run for an element of the contributor dimension to which they do not have access.

So in short, I would avoid giving users direct access to edit dimensions, unless it is in a scratch pad model to which only they have access, but if it is a shared production model then I would give them cubes to type in the elements they want to create and a TI process to update the dimension, and you can include in the TI process whatever validation checks you need. In practice we always update a copy of the dimension and then apply only what has changed to the master dimension. This reduces locking and ensures that any errors caused by the update can generally be identified by validation checks on the copy before the master dimension is affected.

Regards

Paul Simon

[tsw]

The user probably has Analyst permissions in Workspace. To gain access to the modelling capabilities they need to be set up as a modeler or admin (workspace groups not tm1 groups.)

Hi Declan,
Yes, I changed role in PAW to Modeler, but that still doesn't work in PAW.
Thanks for your suggestion!

[tsw]

Hi

We provide the ability for users to update dimensions, but not directly. In my view it is easy enough for an experienced developer to make a mistake using the Dimension Editor, let alone an end-user.

In our situation we have many contributors with their own local chart of accounts. They need to be able to update that and provide a mapping to the central chart of accounts.

...
Paul Simon

Hi Paul,
I'm going to back up and keep the dimension to help solve the issue of user mistakes. We've considered and even created an application to manage the financial statement lines. But ultimately decided on allowing the direct edit since it's pretty intuitive thru PAW. Combined with real-time edit and reload of data, the accounting user can reconcile consolidated bs, p&l , etc quickly in PAW.
Thanks for your suggestion!

[paulsimon]

Hi tsw

Presumably, you are aware that if the user accidentally deletes an element, that they lose the data from the cubes, not just the element? Even if the element is a consolidation, deleting it will take it out of subsets, that can then affect views and in turn processes. It can also invalidate rules. There is also the issue of locking. There are also audit issues. There are also the licensing issues that Steve raised. I don't know the full circumstances of your situation, and may be the approach you are taking is right for your situation, but I haven't seen too many cases in the past when it would be the right way to go. As I said earlier, possibly if the dimension and cubes using it are only used by a very small number of users.

Regards

Paul Simon

[tsw]

Hi tsw

Presumably, you are aware that if the user accidentally deletes an element, that they lose the data from the cubes, not just the element? Even if the element is a consolidation, deleting it will take it out of subsets, that can then affect views and in turn processes. It can also invalidate rules. There is also the issue of locking. There are also audit issues. There are also the licensing issues that Steve raised. I don't know the full circumstances of your situation, and may be the approach you are taking is right for your situation, but I haven't seen too many cases in the past when it would be the right way to go. As I said earlier, possibly if the dimension and cubes using it are only used by a very small number of users.

Regards

Paul Simon

Hi Paul,
Yes, I'm aware. The data comes from our consolidation tool and so this application/cube is just loading the data for reporting/reconciliation purposes.
They love what we created, just having issue with the permissions from PAW.
Thanks!