security overlay - what am I doing wrong

[stingo]

Is there a piece of knowledge I am missing?
am I getting crazy?

I am trying to create a security overlay cube in my PnL cube ('PA on cloud').
I am creating the cube with the appropriate mapping (in a security TI).
Then I apply
SecurityOverlayCreateGlobalDefault ('Profit and Loss', '1:1:0:0:0:0:0:0:0:0:0:0:0:1:0:1:0');
I check the cube and it is there with the appropriate dimensions as a node.
I then lock a node with the following
SecurityOverlayGlobalLockNode(1, 'Profit and Loss', 'Actual|Company3|Mar 2025|Import');
I check the cube and as if it was magic, the overlay cube contains exactly 1 (lock) in the cell I want to lock.
I then proceed to Refresh the securities (never the less it should work without) just because redundancy.
then I go to a random cell containing the node I just locked, I delete the content and it goes to 0. I put a random number and the cell changes.
So essentially I locked nothing.
I even tried SecurityOverlayGlobalLockCell just as a test and I still achieve nothing.

So the question is, what am I actually doing wrong?

[MarenC]

Hi,

I don't believe the Security Overlay affects Admin users, are you an admin user? Have you tested a non admin account?

Maren

[stingo]

I am an admin but I have an account that is data admin too.
I removed the data admin status on the account and assigned it to some random groups and still no cigar.
I can still write and clean with the no more data admin account.

[gtonkin]

And now there are two of us using security overlays...

In my scenario I am using rules to set the OverlayData to 1 to block intersections.

Data admin can write to these intersections but a TI process that runs as a pseudo-data admin cannot and you need to apply CubeLockOverride in cases where this may be needed.

With that said, I would recommend testing on another user that has no built in Admin roles and seeing if they are blocked, as they should be.

[stingo]

I removed the data admin status from the account but it is still an highway, I can write, clean, rewrite etc.

I would like to lock cells to everyone but this is not really working.

[gtonkin]

Try adding a rule with the following:
['OverlayData']=S:'1';

That should block all input across the defined dimensions, assuming no admin user. On PAoC, ensure the test user is not a subscription admin or similar too (CAMID groups).

[stingo]

Try adding a rule with the following:
['OverlayData']=S:'1';

That should block all input across the defined dimensions, assuming no admin user. On PAoC, ensure the test user is not a subscription admin or similar too (CAMID groups).

I tried via rules.
I tried via TI.

The Overlay is 1.

I can write with Admin, I can write with Data Admin, I can write with no admin, I can write with a TI.

EDIT for clarity:
I created a view with one cell that is closed in the Overlay.
I created a TI that does nothing else than put '1000' in the cell I am looking at.
The TI is successful and the cell is now 1000.

[stingo]

just for the records.

I queried IBM and they confirmed that I am not losing my mind, TIs are not impacted by the layer.
essentially it is an useless feature as you can just put the cell on read.

[Wim Gielis]

And that is why only you and George are using the feature….

[stingo]

if you have a better idea, be my guest.

[lotsaram]

What's your actual requirement?

I never in 25 years so far working with TM1 found something that can't be solved with cell security. I see no need for the overlay cubes TBH.

[stingo]

What's your actual requirement?

I never in 25 years so far working with TM1 found something that can't be solved with cell security. I see no need for the overlay cubes TBH.

sorry went radio silent.

the idea is that I have hundreds of TI on the server and I want to avoid people to run a perfectly working TI on a non perfect cell.
with people I mean everyone.

Normally I could just open close a month and it will work for 99% of TIs. but I just need someone to run the 1% and we are calling a backup.

I tried cellsecurity but I cannot lock. I can only put it to read and we are on the same situation

[lotsaram]

TI is always running with admin rights and ignoring security and security overlay.

So If you don't want the TI to be able to run in certain circumstances (e.g. a submission being "locked") then you need to build in your own custom lookup and abort logic into the prolog. Whether the lookup logic references cell security, security overlay or just a status cube that's not actually linked to the security model doesn't really matter, but it is something that you need to do to make this work.

Why IBM never addressed the very often requested feature to have a switch for TI processes to run with the rights of the logged on user rather than as admin which would make such workarounds irrelevant, your guess is as good ans anyone's, ... maybe we might get this in v12?

[Wim Gielis]

True. You can (and should) build such a mechanism yourself.

Even better would be a generic TI that is called and returns the outcome (based on the parameter values, user (or chore), "area" (what type of process is run) and any other logic needed to decide: continue or not. That way, your hundreds of TIs will be easier to manage when it comes to the above. No one will want to maintain the same or similar logic in hundreds of processes.

[gtonkin]

For my 2 cents, it works for me.

The GIF should demonstrate how I use the overlays to block off scenarios e.g. snapshots and periods on the rolling forecast that are not relevant and should not be input. My overlay cube for the demo only has two dimensions: Scenario and Period.

Essentially when I block Actuals and the Period e.g. 2021-JUL, my test user interacting with the objects on the right of the screen cannot update.
On the left is my admin user who has permanent access and can update the overlay cube.

Note too that the process does not run as a full admin as this would allow a write to the cube. Only when I override and use CubeLockOverride, can the test user write to the cube. TI user is thus not always equal to Admin privileges.

Security Overlays.gif (3.42 MiB) Viewed 16732 times

[stingo]

guys I know that I need to put logics to avoid writing on closed months and as I already mentioned, I am not catering for the 99% of TIs that are written good, I am trying to cater for the next 1%.

I have hundreds of TIs in the system and I don't have the time (as it is not the focus of my project) to check all of them to fix them.
I just wanted a catch 22 to simplify my client life.

[stingo]

For my 2 cents, it works for me.

The GIF should demonstrate how I use the overlays to block off scenarios e.g. snapshots and periods on the rolling forecast that are not relevant and should not be input. My overlay cube for the demo only has two dimensions: Scenario and Period.

Essentially when I block Actuals and the Period e.g. 2021-JUL, my test user interacting with the objects on the right of the screen cannot update.
On the left is my admin user who has permanent access and can update the overlay cube.

Note too that the process does not run as a full admin as this would allow a write to the cube. Only when I override and use CubeLockOverride, can the test user write to the cube. TI user is thus not always equal to Admin privileges.

Security Overlays.gif

what version are you running?

as IBM is adamant doesn't lock TIs anymore.

[Wim Gielis]

What I observe in my tests is:
• a user in the ADMIN or DATATADMIN group can write to the overlay security locked cell
• a user not in the ADMIN and not in the DATATADMIN group cannot to the overlay security locked cell
• a user in the ADMIN or DATATADMIN group can run a TI that writes to the overlay security locked cell
• a user not in the ADMIN and not in the DATATADMIN group can run a TI that writes to the overlay security locked cell but it stops with an error on that write action

Seems to me like this is what you need, unless you also want to stop the admin and data admin users.
Also, cell-security on WRITE for the cell will not override the overlay-secured cells so a READ for overlays cannot become a WRITE because of cell-security.

Basically, you have to see the security overlay cubes as a shortcut to not having to insert S: 'READ' kind of rules statements in a cell security cube near the very top of the cube rules, applicable to all normal/business user groups in 1 go. Just a shortcut, nothing more. Which means also that you now define the rules in 2 places. However, in the absence of cell-security and when non-admin groups can be treated equally for certain cube slices, security overlay cubes can be very useful. These cases are rather rare to be honest.

With cell-security equal to READ or even NONE, the user can still execute the TI and write to the cells. This is probably your use case. Then, a central cube to lock certain scenarios/versions/periods(/companies) then secure the overlay cubes with rules looking at that cube, could be sufficient:
- to avoid writing/adjusting many or all the TIs
- when users are not admin or data admin
- you can live with TI error messages rather than your own custom messages (non-admin users cannot easily see the server logs)
- cell-security is probably set to READ for the cell although that is not a requirement

Overall, I do think that security overlays can be useful. Not in every cube in every model, but still a good number of cases. Being able to stop certain TIs from clearing and loading data is handy.

[gtonkin]

...what version are you running?
...

TM1 Build Number: 11.8.02800.9 (2.0.9.20 IF2)

[stingo]

What I observe in my tests is:
• a user in the ADMIN or DATATADMIN group can write to the overlay security locked cell
• a user not in the ADMIN and not in the DATATADMIN group cannot to the overlay security locked cell
• a user in the ADMIN or DATATADMIN group can run a TI that writes to the overlay security locked cell
• a user not in the ADMIN and not in the DATATADMIN group can run a TI that writes to the overlay security locked cell but it stops with an error on that write action

Seems to me like this is what you need, unless you also want to stop the admin and data admin users.
Also, cell-security on WRITE for the cell will not override the overlay-secured cells so a READ for overlays cannot become a WRITE because of cell-security.

Basically, you have to see the security overlay cubes as a shortcut to not having to insert S: 'READ' kind of rules statements in a cell security cube near the very top of the cube rules, applicable to all normal/business user groups in 1 go. Just a shortcut, nothing more. Which means also that you now define the rules in 2 places. However, in the absence of cell-security and when non-admin groups can be treated equally for certain cube slices, security overlay cubes can be very useful. These cases are rather rare to be honest.

With cell-security equal to READ or even NONE, the user can still execute the TI and write to the cells. This is probably your use case. Then, a central cube to lock certain scenarios/versions/periods(/companies) then secure the overlay cubes with rules looking at that cube, could be sufficient:
- to avoid writing/adjusting all the TIs
- when users are not admin or data admin
- you can live with TI error messages rather than your own custom messages (non-admin users cannot easily see the server logs)
- cell-security is probably set to READ for the cell although that is not a requirement

the pseudo account is apparently admin even if it is not.

So a chore scheduled will run and write.

Tested and and I can confirm.