TM1 Forum

Hi

User 1 (Non Admin) - Locks Element "A" in the dimension "XYZ"
User 2 (Non Admin) - Tries to Unlock the element "A" in dimension "XYZ" (this user has got Admin Access to element "A") - Unable to UnLock - Why?

User 2 has got Admin access to the dimension "XYZ" (which holds the Element "A") as well. Also tried giving user 2 Admin Access to the }ElementProperties_XYZ cube - Still No Luck

As an Admin I can unlock the element "A" - which is fine, cauz Im under the Admin Group

Would appreciate if anyone tried the above scenario and were successfull. Thanks

Have you tried the lock and reserve security groups for user B?

also

I think only the person that locks the element can unlock it?

I think the documentation may be incorrect too, I'm pretty sure that even full admins cannot edit locked data, which is not what the docs state

TM1 Developers Guide 9.5.1
"When a user locks an element, only those users who have Admin rights for that element can update the data that it identifies. Even the user who locks the element cannot update its data, unless they have Admin rights for that element."

I don't think the above from the docs is correct? Don't have a lot to do with security tbh so could be wrong....

Cheers

The docs are definitively wrong on this one. The primary reason that we use locking is that it means NO ONE can edit data, including admins, including TI.

However in relation to the question from the OP the way we use it is that users only ever have write access and all the locking is done by admins and in this scenario any admin can unlock regardless of who did the locking. Providing the user has admin rights to the particular object I would have thought this would hold true for non admins as well but by the sounds of it maybe it doesn't.

Manage to do a trick to overcome this. Assign user 2 to the Admin group and then Unlock the element and then remove the user from the Admin group.. Worked for me...



CubeLockOverride(1) ;
nChangeStatus = 0 ;

sCheckGroup = CellGetS( '}ClientGroups' , 'User 2' , 'Group' ) ;

IF( sCheckGroup @= 'ADMIN' );
ELSE;
AssignClientToGroup( 'User 2' , 'Admin' );
dChangeStatus = 1 ;
ENDIF;


cCubeName = '}elementproperties_XYZ' ;
cEleName = 'A' ;

CellPutS( '' , cCubeName , cEleName, 'lock' ) ;

IF( dChangeStatus = 1 );
RemoveClientFromGroup( 'User 2' , 'Admin' );
ENDIF;

Hi Sameer - I would be REALLY surprised if the code you provided works! The reason being that when an element is locked that this applies also to the intersection of LOCK and the element in the }ElementProperties_Dimension cube which means that the cell is not writeable even by a member of the admin group. the element must be unlocked before the blank value can be sent, it is what you might call a "Catch 22" situation. (Possibly you tested when the element "A" was not actualy locked.) Also as the TI process is already running with admin rights regardless of who kicked off the process adding and removing a user to the admin group within the prolog doesn't actually achieve anything.

The only OOTB method TM1 gives to unlock is via the subset editor GUI in the right-click > security menu. In theory you could do a roll your own programatic way via the API but it would not be an easy route.

Using CellPutS to write to the }ElementProperties_Dimension cube to lock an element on the other hand works just fine. it is only the unlocking that is the problem.

Lotsaram

It's the CubeLockOverride(1) that does the trick of allowing a TI to run above its normal Admin level and unlock cubes. This gives you a programmatic method to unlock without resorting to the API.

John

John Hammond wrote:Lotsaram

It's the CubeLockOverride(1) that does the trick of allowing a TI to run above its normal Admin level and unlock cubes. This gives you a programmatic method to unlock without resorting to the API.

John

Hmmm, I missed that.

But_this_would_be_an_undocumented_function !
I can find it in the 9.5.2 documentation in the list of reserved words but nowhere else.

I like it. It means it is possible to provide a simple TI programmatic interface to unlock as well as lock elements which can be very helpful in certain situations. What I do not like is the fact that the function is undocumented.

@Sameer as per what john has highlighted it is CubeLockOverride that is your secret sauce here. You can remove the adding and removing the user from Admin group, as this isn't doing anything useful.

@lotsa, but of course it's documented!

In the Iboglix style it's documented in the release notes.

qml wrote:@lotsa, but of course it's documented!

In the Iboglix style it's documented in the release notes.

Thanks. How obtuse of me not to have noticed.

Interestingly the function (as per the 8.4.5 release notes - thanks for the link ) is supposed to override cube locks but it would also appear to override element locks as well. Therefore one suspects that the mechanism by which this works just "peels off" the additional layer of locking which behaves like an extra layer on top of standard security (but as this behavior is undocumented who knows, that's just wild speculation on my part.)

@Lotsaram - I tired without assigning the user to the Admin group - It doesn't work. It manages to clear the cell but for some reason it continues to be greyed out.
so having both the CubeLockOverride function and assigning/removing user from the Admin group seems to be the only solution I have at the moment.

Hi
I am facing the similar issue with 10.2.1, when trying to unlock the cube with a normal user.
Also Provided the Admin access to the user on that cube,. still its not working.
Its able to execute the below command
CellPutS( '' , cCubeName , cEleName, 'lock' ) ;
Means reset the Lock to blank. But cube is still in locked status.
also when I tried to use the suggestions provied above.i.e.
CubeLockOverride(1) ;
and assigning the user to ADMIN group the process is failing at AssignClientToGroup( 'User 2' , 'Admin' );
Not enough privilegs to execute this function.
Any help would be appreciated.
Thanks!

ruchika512 wrote: Not enough privilegs to execute this function.
Any help would be appreciated.
Thanks!

When you are using any security based function and the process is being run by someone who is not an admin at the start of the process you need to right-click on the TI in question and select security access; this allows it to be run with elevated levels of access.