TM1 Forum

I'm looking to find anyone else who is using Contributor and C8 Security for 9.5.2, and has encountered issues with corrupt sandboxes, resulting in users being unable to commit their data. This issue is supposed to be fixed in Fix Pack 2 (per PM45586).

We are on 9.5.2 Fix Pack 1 and are having problems with users being unable to commit their data, due to their sandboxes somehow becoming corrupt. We have a service request in with IBM right now and they are investigating to find the root cause of what is causing the corruption. However the corruption appears intermittently so we have not figured out a way to reproduce it reliably yet, which means they haven't figured out what's causing it. Also, since we can't reliably reproduce the problem with the same test case as for PM45586, they're not sure if what is occurring for us is a new issue or somehow that same issue with different circumstances, since the end result (sandbox logs corrupt, user unable to commit) is the same.

Since the problem occurs intermittently, if we do install Fix Pack 2 it will be very hard to prove the issue is resolved since the only way to know for sure, is if the problem never occurs again. So I'm trying to find out if there is anyone else who experienced this issue with 9.5.2 FP1, and considers it resolved after installing FP2. Even if this occurred more predictably as in PM45586, that would be helpful, but it would be even better if someone has had the same intermittent problems we have seen. I'd also be curious if anyone has seen this issue even with FP2 (I'm hoping not, but would rather know now if it seems like FP2 won't fix our problem).

Thanks in advance for any replies.

We had this issue last month (before FP2), and we installed FP2, but still sees this issue yesterday and today. (we use 9.5.2 with Cognos BI 10.1 security). Symptom is intermittent and happens on about 1/10 of our Contributor users. The main symptom is - user took ownership, entered data, can't commit, data remains blue.

Last month (before FP2 was installed), some users tried a workaround -- create a named sandbox, commit and submit the sandbox. That worked. But after we installed FP2 earlier this month, the workaround wouldn't work any more -- the sandbox commit doesn't save data into system; plus, the sandbox itself disappeared after user logs back in. (was it designed like this? once you committed a sandbox, it is removed from the system?)

Today we tried another workaround to save user's entries -- set user as a "data admin" in TM1 security, then user is able to commit his contributions. and then revert user's role.

http://www.tm1forum.com/viewtopic.php?f=21&t=7770
Here you can find links to posts about similar problem (maybe even the same).

This morning one of our developers (seems with smarter brains than me) gave us reason explanation.
We have several version of budget - elements of dimension. We set version #1 of budget to 'READ'. After that we changed some calculation in all model. Users' sandboxes include "old data", that differs from our "new, right data". So it becames blue. And user is unable to commit. And maybe FP2 will not help. We haven't tried.

#Added later:
is it possible to destroy all users' sandboxes with setting some budget version READ ONLY?
http://publib.boulder.ibm.com/infocente ... ommit.html I would like to place this link here
http://www.tm1forum.com/viewtopic.php?p=32583 and this too

I had forgotten to update this post, so thanks for reminding me.

It turns out for us that apparently security is the problem (here's a thread I started on questions about that: http://www.tm1forum.com/viewtopic.php?f=3&t=7719

We can't exactly prove it, but supposedly FP2 does fix the main corrupt sandbox issue, but in our case that wasn't the only problem causing the data to not commit. We did figure out a way to reproduce the issue, and even after FP2, we can still get the problem - it's a convoluted series of steps (that doesn't match anything a user would actually do, and we can't explain at all why these particular steps cause the problem), but works every time. According to IBM this is because the user doesn't have WRITE access to some of the cells being committed. So this actually matches what ioscat describes, although not what hxp417 is describing (although if giving a user data admin access fixes the problem, maybe it is security related?). Our difference though is that the user NEVER had WRITE access to the cells in question (cells are updated via rules, not by direct user data entry, so we had set security as READ), but can initially commit their data, and then suddenly their data no longer commits. When we update our security so users have WRITE access to all cells that could be updated, so far we have been unable to reproduce this problem, so security does seem to be the issue.

We had come up with a workaround for our commit issue, not ideal, but it was ok. If a user encountered this problem, but only had a small amount of uncommitted data, they could reset their data themselves, which would delete the corrupt sandboxes. Then they would reenter their data and continue working, and were able to commit again. Our workaround for if they had a lot of uncommitted data was for them to export that data into Excel, we'd remove the corrupt sandboxes, and then we'd import the data on the backend. Definitely not ideal for many reasons.
We never tried anything with creating named sandboxes before we installed FP2, so I can't speak to that solution. However I tested now, and creating a named sandbox didn't allow us to commit, once the data became uncommittable. I've never seen a sandbox disappear after committing, but they do disappear once the node is submitted - my understanding is that is normal functionality, since the sandbox isn't really relevant, once the user submits the node.

In response to ioscat's question above, if FP2 will help, if it's a security issue, the answer is no. If a user doesn't have WRITE access to something that appears to need to be updated as part of them committing their data, the commit won't work and the data will stay blue. At that point some workaround needs to be used to get rid of the sandboxes that won't commit, and to get the uncommitted data into the database. What we are trying to do now is review all of our security, to make sure we don't get into this sort of a situation again. The only unanswered question for us is it still doesn't make sense, why sometimes the user could commit, and other times they couldn't, when our security was not changing.

We are still working with IBM tech support on this issue. I just verified with the IBM guy -- that is not true -- you need to have write access to all cells which will be updated by the data commit.

This might be a workaround for now, but, in my opinion, this is horrible application design if it's true -- because, data flows from one cube to another cube to another cube.... every time you add cubes, add/change rules, you would have to worry about changing user security settings, even if the new cube is strictly for reporting only. etc, etc.

When I create Contributor models I always isolate user input into a separate cube(s) to keep crazy stuff like this from afftecting the rest of the model. You should be able to either move the data with rules and/or TI safely from the input cubes without Contributor messing anything else up.

hxp417, can you clarify what you meant by "that is not true" in your post? I wasn't sure if you meant it was true, or was not true, that a user needs WRITE access to all cells which will be updated by the data commit.

tomok, are you saying that as long as other cells affected by the data commit are not in the same input cube where a user is entering data, that user doesn't need WRITE access to the other cube/cells as well, and their data should commit? Our input cubes are relatively separate, except that we have some input cubes that have data coming from another input cube. So a user could have multiple roles affecting their access to the input cubes. That is my big concern right now, as we work to fix our security, as we have situations where a user has WRITE access to some cubes based on their role, where they enter data. However that data then flows to another cube, where that user either 1) doesn't have access to the cube at all or 2) has access to the cube, but not that intersection of the data. That's because we have data flowing from a specific program/department, to a central department, but the user for the specific program doesn't have any access to the central department where their data is flowing to.

Hi lpahnke,

If I were you, I wouldn't bother changing cube/element securities for this bug at all. I already verified with IBM Tech Support, he told me you don't need write access to those cells indirectly affected by contributor data entry. It is ridiculous if they designed things this way (you need write access to any cell that will be updated by data entry); no one would ever design their software this way. It is simply wrong.

-----------------------------------------------------------------------------

I guess it is more of a "data out of sync" problem -- for example, user A took ownership of the data (1, 2, 3), and changed them to (1, 4, 3), he didn't commit and left it behind, the temp data is saved as his personal work space or sandbox, either way, and remains on the server.

User B opens the node, took ownership from A, changed (1, 2, 3) to (1, 2, 6), then committed data.

Then user A open this node again and took ownership back, his data is still (1, 4, 3), and entered a lot of other data, when he tried to commit, for some reason (it is the bug here), the server thinks his personal work space is out of sync and invalid, thus doesn't let user A commit. If he reset data, he lost all his entries, but he has nowhere to go.

so far IBM has not given any feedback, they can't reproduce this issue, they have not recognized this problem yet.