Element security - where is WRITE access required?

[lpahnke]

We are encountering problems where users in Contributor are unable to commit their sandbox data. Initially they don't have a problem, but at some point many users encounter an issue where their changes remain in blue font, and their data isn't committed. We reported the issue to IBM, and have been told that in part it is a known issue fixed in 9.5.2 FP2 (which we are in the process of installing/testing this week), but also in part due to security in our model. They have said that some of the data changes that are attempting to be committed to a user's sandbox are to cells where the user doesn't have WRITE access, and that's why it fails. However the user's security is definitely not changing in between commits, so it's not clear why it fails sometimes and not others. I have at least figured out a way to reproduce this issue, through a series of steps, I just can't figure out why those steps cause the issue, and yet others do not (in short I can commit three times, but on the fourth attempt it doesn't work, in addition to some other specific actions I take).

We do have security implemented via rules in some }ElementSecurity cubes to control users (via their roles) having READ vs. WRITE access to certain elements. One example IBM gave was with an element where all user roles who have access to the cube have READ access only (although no one can write to it, since it's actually rules-calculated). So the reason it's getting updated at all as a change in their sandbox is because they've updated other cells that are part of its calculation. For this particular element, we could remove the READ restriction (since it's rules-calculated anyway), but my understanding is that because we are using rules in the }ElementSecurity cube, we would need to give explicit WRITE access to fix the problem we're having, since going from READ to nothing wouldn't give the user the access they needed. For this element (and probably others we're handling similarly) that's fine, if that's what we should be doing.

My question is how far this needs to go. We have users with roles where they don't have access to certain cubes (security handled in }CubeSecurity, which is set via a TI process). But our model is set up so that a user could update data in one cube (say cube A) that via rules, affects data in cube B, where that user/role doesn't have any access, both at the }CubeSecurity and }ElementSecurity level. What I'm not clear on is if that limitation will then continue to cause problems with committing their data, so if even if we fix }ElementSecurity, will some users still encounter this problem due to the overall data flow in our model, and their access or lack of access to parts of it.

Obviously I can (and will) test this, but what we'd need to change and test could potentially affect a lot of our model, given how it's been set up. So I wanted to make sure I understood the concept and what was needed first, in case it is not all necessary, or in case I encounter other problems with our security, if I'm missing something. So if anyone has any suggestions or can point me to more information on this (I looked but didn't find documentation on this sort of a situation) I would appreciate it.

[Steve Rowe]

Hi,
Can't help with your actual problem but IBM seem to be telling you the following.

You have a rule that says a = b *c say.

If you have only Read access to a then you can not write to b or c irrespective of what security you have on those elements.

Am I misreading what you have written?

If they are saying the above then I would say that is a bug itself or at least a big departure from traditional behaviour.

Cheers,

[lpahnke]

You are correct with how you've read what I've written.

The only difference might be that IBM is not explicitly saying that you must have WRITE access to 'a' in order to WRITE to 'b' or 'c'. But IBM is implying this, in saying that security in our model is causing the problem, and specifically it is security not allowing WRITE access to cells such as 'a'. They also haven't said that it's the updates to 'b' or 'c' that cause the problem with 'a', but have only said the problem is 'a' is being updated when the user doesn't have the correct privileges. We know that in our model the only way the user is "updating" 'a' is through changing 'b' or 'c', which we've told IBM, and they've come back to say again that security in our model is the problem, so again implying that a user has to have WRITE access even for rules-calculated cells.

Also, in case I've implied anything correctly, in this case users don't get an error that they don't have access to a cell, the only symptom that there is a problem is that they can no longer commit their sandboxes.

So IBM is saying that the reason a user can't commit is because of the inability to commit data for cells they don't have WRITE access to. Their suggestion on why this does not occur all the time (that is, a user can make changes to 'b' or 'c' that affect cell 'a' and commit those changes successfully some of the time) is that security is changing, so the user can commit when they have WRITE access, but they encounter a problem when they try and commit changes and the WRITE access is no longer there. The problem with this idea is that the security is not actually changing in our model. The users have never had WRITE access to the cell in question.

I've asked IBM to clarify why this problem is not occurring all of the time if it's truly a security issue, and also if they are saying we need to give explicit WRITE access to rules-calculated cells in order to allow users to commit, since I agree that this behavior doesn't look normal (or at minimum doesn't seem to be documented anywhere).

[BigG]

because we are using rules in the }ElementSecurity cube]

Is there something up withthe rules within the security cube. Do you need it to be rule driven? could you test this through a TI process update that defines WRITE and READ access the same way your rules do. Then it is a cell value rather than rule result... this could eliminate that being a problem if you could run a test

[lpahnke]

Quick update on this, since I mentioned it on another thread...
We changed our security rules to give users WRITE access to all elements that could be updated by their changes, even indirectly. So far that seems to have fixed the problem - I haven't been able to reproduce the problem of a user being unable to commit.

[hxp417]

We are having the same issue here. Very frustrating. TM1 Contributor users have entered data but can’t COMMIT in the system. During this struggle, they’ve lost their work, sometimes several days worth of work.

[adaptive_tech]

Greetings all

I encountered this same problem: one of my nodes was stuck, returning an error that data was saved in a cell intersection which wasn't allowed by security; however, even after changing the rights to WRITE, copying 0 over everything, and turning the rights back to READ, the error persisted.

The good news is, I found a solution:

I figured that it had something to do with the Sandbox copy of the data not working properly with the new Security settings; so, I executed the following steps:

* Log in as the node-level user and open the node. In the upper-right, click the Sandbox button -> Create a new Sandbox. I named mine "Temp". Note that this new Sandbox will be a perfect copy of all your data that you (presumably) want to retain.

* Commit your work. This should save properly and turn from blue to black.

* Submit your plan, then log out.

* Log in as Administrator and reject the submission.

Everything should be fine now -- the data should be saved and in the system, and everything should now be in the node-level user's "Default" Sandbox (note that "Temp" will disappear).

Please share results of this technique -- I wanna see if it works for everyone.

[lpahnke]

Sorry for the delay in replying.
This workaround doesn't work for us. The new (copied) sandbox has the same problem. However in our case we also never get any kind of an error related to security, and the issues we encountered weren't related to security changes (our security setup was never changing, just sometimes users couldn't commit). I think your workaround sort of makes sense though, where the problem is occurring when the sandbox settings have changed, as a way to not lose data and get around that error you were seeing.