TM1 Forum

Hi All,

wanting to implement a one-way switch in TM1 9.1 as follows;

1. User enters data into cube via workbook against a particular element.
2. User indicates completion.
3. Element needs to be locked until released by Manager.

This would be easy to do by TI (just have the TI lock the element) but needs to be done without running a TI.
Difficulty seems to be that anything done by a user to lock the element (attributes, rules etc.) can also be un-done by that user.
I realise this is a workflow type scenario but there must be some simple way to do this in native TM1, surely.

Any ideas?

thanks,

Gregory

GPC wrote:Hi All,

wanting to implement a one-way switch in TM1 9.1 as follows;

1. User enters data into cube via workbook against a particular element.
2. User indicates completion.
3. Element needs to be locked until released by Manager.

This would be easy to do by TI (just have the TI lock the element) but needs to be done without running a TI.

May I ask why? It's possible to allow users to run TI's, and since they run with Admin permissions it solves your main problem, which is:

GPC wrote: Difficulty seems to be that anything done by a user to lock the element (attributes, rules etc.) can also be un-done by that user.

The TI is therefore able to lock the element, but the user can't unlock it. The manager, being in a different security group, could run a different TI to unlock the element.

I've never done this myself, but I can't see any reason why it shouldn't work. Off the top of my head I can't think of another solution since, as you've said, you need something that the user can't undo.

I recall doing something that accomplished what you want, but with a different approach

1) User enters info in cube under scenario "Pending Approval"
2) Manager reviews
3) Manager approves by running a TI that loads only that departments information into a "Approved" scenario

* Approved Scenario is only read for all users, but since TI runs as ADMIN it can write the data to the scenario

I did this some time ago using rules (partly in security cubes). We were demoing TM1 Workflow which doesn't actually lock anything and I needed to show users could lock their own data. It was relatively fiddly.

Can do it with a cell security rule

['Input cell', 'Group'] = S:
if(db('SettingsCube', !InputCell, 'Complete')@='Yes', 'READ', 'WRITE');

So the user puts 'Yes' into your SettingsCube, which then means the cell security will fire and lock the cell.

Cheers,
Martin

Martin Ryan wrote:Can do it with a cell security rule

['Input cell', 'Group'] = S:
if(db('SettingsCube', !InputCell, 'Complete')@='Yes', 'READ', 'WRITE');

So the user puts 'Yes' into your SettingsCube, which then means the cell security will fire and lock the cell.

Neat, but wouldn't that still have the problem that Gregory mentioned of being undoable by the user via them clearing the Settings Cube value? Or am I missing something?

You can have the same security in the settings cube so that as soon as the flag is set by the user it becomes read only.

Steve beat me to it, but here it is anyway...

You could also have cell security on the SettingsCube

['SettingsFlag', 'Group'] = S: if(DB('SettingsFlag', !Area, 'Value') @<>'', 'READ', 'WRITE');

That way as soon as the user signs it off, they are unable to change their mind.

I currently use that method for one of my processes. A user signs if off, then they cannot write to the cell that they just wrote to in order to sign it off.

I was initially concerned it might cause a circular error somehow, but it didn't.

Martin

Martin Ryan wrote:Steve beat me to it, but here it is anyway...

You could also have cell security on the SettingsCube

['SettingsFlag', 'Group'] = S: if(DB('SettingsFlag', !Area, 'Value') @<>'', 'READ', 'WRITE');

That way as soon as the user signs it off, they are unable to change their mind.

I currently use that method for one of my processes. A user signs if off, then they cannot write to the cell that they just wrote to in order to sign it off.

I was initially concerned it might cause a circular error somehow, but it didn't.

The thought briefly flitted through my mind, but I dismissed it as a circular issue as well. But upon reflecting there's no reason why it should be since it's about security rather than values.

Doubly neat, then!

Hi All,

thanks for the great idea, I haven't tried it but looks like it should work a treat. What I found when trying to do it with rules is that a security refresh seemed to be required which takes up to minute on our Prod server. I also managaed to crash the dev box a few times trying to get cell security rules working.
In the end, however, I went for the TI approach - the reason I didn't want to do it this way initially is that there are approx 30 companies to Lock & I didn't want to have that many TI's run. However, it is a nice simple solution.

Eric, this is a good idea and one which we quite often use.

Thanks again,

Gregory