TM1 Forum

Hi,

When we apply element level lock what we have found is it restricts manual input, but if anybody updates data using TI then it allows to update.
Can anybody help me in understanding how to restrict data updation via TI when we lock the element.

Please have a look at it:

http://www.tm1forum.com/viewtopic.php?f=3&t=7342 Thanks

radhikah78 wrote:Hi,

When we apply element level lock what we have found is it restricts manual input, but if anybody updates data using TI then it allows to update.
Can anybody help me in understanding how to restrict data updation via TI when we lock the element.

Element locking should prohibit data entry by admin users (that includes TI). If is doesn't then that's a bug, what version are you using?

Does the TI process contain the function CubeLockOverride(1) in the prolog?

BariAbdul wrote:Please have a look at it:

http://www.tm1forum.com/viewtopic.php?f=3&t=7342 Thanks

BariAbdul, I'm really not sure of the relevance of the link you posted.

Sorry,I should have read carefully.

Hi,

We are using TM1 10.2.1 version.
The TI's that we have written does not have function CubeLockOverride.

radhikah78 wrote:Hi,
When we apply element level lock what we have found is it restricts manual input, but if anybody updates data using TI then it allows to update.

That's exactly correct. Essentially every TI runs as admin regardless of the user who executes it. That's why they need to be created by an admin and why an admin needs to define who has access to see and run the TI process.

http://www-01.ibm.com/support/knowledge ... ml?lang=en

Post by BrianL » Mon Apr 27, 2015 8:04 pm
radhikah78 wrote:
Hi,
When we apply element level lock what we have found is it restricts manual input, but if anybody updates data using TI then it allows to update.


That's exactly correct. Essentially every TI runs as admin regardless of the user who executes it. That's why they need to be created by an admin and why an admin needs to define who has access to see and run the TI process.

http://www-01.ibm.com/support/knowledge ... ml?lang=en

Thanks BrianL ,That's exactly what I was trying to say.

BrianL wrote:

radhikah78 wrote:Hi,
When we apply element level lock what we have found is it restricts manual input, but if anybody updates data using TI then it allows to update.

That's exactly correct. Essentially every TI runs as admin regardless of the user who executes it. That's why they need to be created by an admin and why an admin needs to define who has access to see and run the TI process.

http://www-01.ibm.com/support/knowledge ... ml?lang=en

I think it may be an idea to take a look at what Lotsaram was saying again. Yes, the process runs as Admin. BUT when an element is locked, even Admins (which obviously includes TIs) should not be able to write to the cell (unless CubeLockOverride(1) is used). Create an N level view. Now lock one of the elements. You will see that even you, as Admin, will then see the cells in gloriously grey and when you right click on the cell and select Edit Status you will be told that you have no write access to the cell until you UNlock it. If TIs can trample over that, regardless of whether they run as Admin, then something is broked.

Edit: Just for laughs I checked that this ran as expected in 10.2.2. Sure enough, "Error: Prolog procedure line (5): Element "Monetary" in dimension "RS_Measures" is locked." As one would both expect and hope. Double Edit: I also checked in 9.5.2 which radhikah78 indicates in their profile as their version (which it may or may not be); same result.

BariAbdul wrote:

Post by BrianL » Mon Apr 27, 2015 8:04 pm
radhikah78 wrote:
Hi,
When we apply element level lock what we have found is it restricts manual input, but if anybody updates data using TI then it allows to update.


That's exactly correct. Essentially every TI runs as admin regardless of the user who executes it. That's why they need to be created by an admin and why an admin needs to define who has access to see and run the TI process.

http://www-01.ibm.com/support/knowledge ... ml?lang=en

Thanks BrianL ,That's exactly what I was trying to say.

Except that it gives the wrong impression for this specific set of circumstances, which is a rarity for BrianL and based on his answers to date was almost certainly down to a misreading of the question than a misunderstanding of the principles. The question of whether a TI runs as Admin isn't important if an Admin can't do a particular thing either. It takes only minutes to test that that's the case, and beats relying on interpreting the manuals (which have been known to be wrong, misleading or at least incomplete on occasion as well).

This would be a surprising bug; by any chance when you say "apply element locking" do you actually nean element level security as opposed to cell locking?

declanr wrote:This would be a surprising bug; by any chance when you say "apply element locking" do you actually mean element level security as opposed to cell locking?

I think you might be onto something. It seems that BrianL may have the right answer through a misreading of the OP's question and Alan has already done the experiment to confirm that Element Locking does not seem to be broken in either 9.5.2 or 10.2.2. Only radhikah78 can say if they actually meant Element (read) Security as opposed to Element Locking, (but if that is the case then an apology is probably in order.) There is a good article covering the TM1 security locking concept here.

Maybe I've gone through this thread too quickly, but...

Reading the fine manual on element security it states:

Locking and Unlocking an Element
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.

Doesn't this imply that Admin rights count higher than Lock rights and because of this someone (or a TI process running) with Admin rights has the ability to write against an element, even when the element was locked by some user?

Michel

Michel Zijlema wrote:Maybe I've gone through this thread too quickly, but...

Reading the fine manual on element security it states:

Locking and Unlocking an Element
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.

Doesn't this imply that Admin rights count higher than Lock rights and because of this someone (or a TI process running) with Admin rights has the ability to write against an element, even when the element was locked by some user?

The manual does indeed imply that, I concur.

And the manual is a bloody liar. I sense another entry for the "Documentation Deficiencies" thread.

Try it out for yourself. As soon as you lock the element, even though you're an admin, you will see the cells turn grey (when you recalculate anyway) and you will not be able to change that value. Nor will a TI process be able to do it unless you use the function which forces the overrride. Otherwise you get the error message that I cited above.

Michel Zijlema wrote:Maybe I've gone through this thread too quickly, but...

Reading the fine manual on element security it states:

Locking and Unlocking an Element
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.

Doesn't this imply that Admin rights count higher than Lock rights and because of this someone (or a TI process running) with Admin rights has the ability to write against an element, even when the element was locked by some user?

The documentation is well, wrong. What it SHOULD say is only the user owning the lock (OR any member of the Admin group) can release the lock. While a lock is in place no user can update, including Admin. This holds true for all lock types; cube, dimension and element. Again how it actually works is explained here (as opposed to what the documentation might claim, which has never been the way locking has worked.)

As any admin can release a lock it is pretty easy for them to get around the lack of write access but does at least prevent unintended changes by unthinking admins.

lotsaram wrote:What it SHOULD say is only the user owning the lock (OR any member of the Admin group) can release the lock.

I think that would be Reserve rights - in case of Lock rights only an admin can undo the lock.

Interesting this - based on the documentation I always assumed the Reserve and Lock rights were just another level in an 'hierarchy' of rights, where the 'higher' right will automatically have priority on the lower right. I thought this was also the reason for having a thing like Security Overlays in TM1 Applications: to be able to actually lock a cell for writing, even for an user with Admin rights.

Michel

LOL BTW - the issue seems to be the application (at least for radhikah78) is behaving as documented