TM1 Forum

Hello!

There is any way to give privileges to a non-admin user edit rules?

Thanks.

manoel.ss wrote:There is any way to give privileges to a non-admin user edit rules?

Sure. It's called "making them an admin and giving them the required training to do that job so that they don't completely screw up your database".

The designers of TM1 did not put in an intrinsic way to give normal users the ability to directly edit rules.

This is because they knew that in the Pantheon Of Really, Really Bad Ideas, this one rates just below "Building a huge dirigible, inflating it with hydrogen, and then putting in a smoking room just underneath the balloon's envelope".

However they did provide a back door for anyone who was bound and determined to do it anyway, which was to include TI functions like Using such functions they can write the rules in a text editor and have the TI load them. You will find these quite well documented in the Reference Guide.

Unfortunately the manual does not address the procedure for "What happens when an end user who believes that they understand rules syntax better than they actually do writes a rule which blows away all of your input data". However the answer to that is backups.

Lots, and lots, and lots of backups.

Hello Alan Kirk.

Thanks for the reply and counseling!

I am studying situations that a exception in a rule should be updated by the "owner" of the cube. As I dont want give acess to that user to edit another rules, your sugestion will help me well, creating a few filters in TI.

The other thing to consider is if the rule needs editing once written then it could (should?) probably be generalised such that it's behaviour can be changed by setting an attribute value.

In your case the exception could be defined by flagging the exception in an attribute rather than direct edit of the rule. There will be some trade off in terms of the efficiency of the rule since the exception will be defined on the right rather than the left however this needs to be balanced against the outage while feeders* are recompiled and the risk of allowing this level of access to the rules to a non developer type.

[{''a' , 'b' , 'c' , 'd'}, 'SomeRule']=N: Stet;
['SomeRule']=N: ['blah'] * ['blah'];

could be replaced with
['SomeRule'] = N: If ( Attrn( 'Alpha' !Alpha , 'Do not Calculate')=1 , stet , ['blah'] * ['blah']);


*This can be mitigated.

While all the usual access-related caveats apply, it is quite easy to give a user access to edit rules for just a single, specific cube. Instead of assigning the user to the built-in ADMIN group (or, a slightly safer option, DataAdmin) you can assign the user to a group who has admin-level cube security rights to the cube in question. Any potential damage would then be limited to that cube only - however the user will be able to do anything with it, including deleting.

To set up cube security in Architect right-click on Cubes, then Security Assignments. You will see that among other levels of access to individual cubes there is also 'Admin'.