Uncommitted Data in Contributor

[cdhodge2002]

I have a user who has entered data but has not committed the changes. But this users superior has gone in and entered all of the needed changes and has submitted the node. Because of this the data that the original user is seeing is different from what the rest of the users are seeing, but because the node has been submitted a reset data can not be run to revert the data to what is in the cubes. Is there an easy way to wipe these uncommitted changes away from the users view?

[Mike Cowie]

Hi:

Yes, I remember hitting this exact problem with a customer and the solution I'd used at the time was something like the following (it was a while ago, so apologies if a bit fuzzy):

• Log the user in (or login as the user) via TM1 Perspectives or Architect
• Browse one of the cubes used in the Contributor app using TM1 Cube Viewer
• Select the Node & Application GUID-named sandbox from the list of available sandboxes (I'm going from memory on the naming convention - hopefully it'll be somewhat obvious)
• Either delete the sandbox or Reset Data here - I think either option will work
• Repeat for any other nodes/users impacted - Contributor makes a sandbox for each node that someone takes ownership of

Incidentally, this is one way you can go in and fix a really screwed up contributor view for a user - as you'll see in the Cube Viewer TM1 creates private views with the Application GUID & Node element name when a user changes their view around in much the same way it creates sandboxes when ownership is taken.

There may be a Contributor TI process that can be used to do the same thing noted above, but at the time I didn't hunt too much for one and haven't gone back since to look at it. I would also imagine you can manually delete sandbox files for the user while the server is shut down, but that's not ideal unless you don't need any of the sandboxes contributor creates and you don't mind having the server shut down while you clean them up.

As you've found with this experience, it's a very bad idea to mix in "back-end", direct updates to fix numbers when using TM1 Contributor and users have been actively working in a Contributor application and have uncommitted changes on any node. It's frustrating that admins have no way of managing these user sandboxes/issues centrally and that you instead have to log in as that user to TM1 Perspectives/Architect (or scan/change underlying data directory files) to see what's out there. But, as far as I know that's the reality.

Regards,
Mike

[cdhodge2002]

Thanks for the information Mike, I was thinking about doing something like this, but was hoping there was an easier solution.

[declanr]

but was hoping there was an easier solution.

Would just deleting and recreating the user possibly work and be quite easy... assuming that you copy all the relevant security info.