Commit Sandbox Numbers Generated by TI

[Derezed]

Hi there,

I have a TM1 Application where a user cannot commit their numbers because their overall sandbox contains numbers generated by TI (with more rights than them).

The only "solution" I have is to grant them write access to the underlying cubes which contain TI generated numbers, however this poses serious data integrity issues (there is a reason these numbers are generated by a TI and I don't want the user to be able to accidentally overwrite them which they would be able to do if they have write access).

My ideal solution would be to get the commit button to run with admin privileges instead of the privileges of the active user.

Has anybody come across this issue and solved it? We thought about adding a process to grant write access pre-commit and then revoke it, but you can't write a pre-commit process!

Another solution would be to have the TI write all numbers to base as it runs, however this is not great since it removes some key functionality (namely sandboxes) from the user. I'd definitely prefer this, but the users tend to disagree!

[Emixam]

When you add the following line tm1s-log.properties and ask a user to try to commit/submit, what do you see in tm1server.log ?

Code: Select all

log4j.logger.TM1.Sandbox=DEBUG

[Wim Gielis]

For a sandbox, the user needs to have WRITE access to the cube, that is certain.
If I understand the problem, you could give WRITE access to measure 1 and load data to measure 2, with READ access.
But then the user cannot overwrite values, it's a delta that needs to be entered.

Now, the flow is that:
- TI loads values
- the user has a sandbox to update the values
- still you are concerned about data integrity and you don't want to have users overwrite the values accidentally. What's the difference with using a sandbox to overwrite values ?

[Derezed]

Thanks guys. The solution to avoid users unwittingly overwriting values that have been TI generated is to have a "Display" measure that is ruled to the value loaded. I think that's what you were suggesting Wim. That doesn't sort users who have direct access to the cube (not through TM1 Applications), but they are not basic users.

It is depending on the TM1 Applications commit functionality that has got us here sadly, otherwise with prudent use of TIs and sandbox functions this would not be a problem.

Cheers