Element Locking and Unlocking (Non Admin Group)

wddr

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

xiaohei3721

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

socaca

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.

fs111

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;

xiphiasjoe

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.

pakyarms

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.