Prevent Data Spread for ADMIN

[Mark2007]

Hi there,

I'm facing the following problem:
in my Web-application, Users enter planning data for the total year (C-Element) and TM1 spreads them automatically to the 12 months below (the months are already populated before, so the system does a proportional spread) - that works fine.

During the planning process, Actual-months come up, so we replace the planned Jan-data by the real (actual) Data for Jan. Security is set to "READ" for Jan and if the Users enter Yearly figures now, TM1 still does the proportional spread, but keeps Jan constant - that's great.

The only Problem: If an ADMIN enters data to "Total Year", this is still spread to all 12 month, even Jan is changed, as ADMINs have WRITE everywhere.

Do you have a problem to prevent ADMINS from Data-Spread to the "closed" months?

Thanks in advance!

Mark

[Emixam]

Hi Mark,

We had a similar issue and we decided to use the }Capabilities cube. Not sure if it will work for Admin

https://www.ibm.com/docs/en/planning-an ... ssignments

Take a look at Allow Spreading.

Also, not sure what you mean by "Web-application". Are you talking about TM1 Web Cube View, Perspective/Pax, Workspace, TM1 Application ?

Let me know if it works

[burnstripe]

You can lock an element by going into the subset editor (legacy subset editor) and right clicking on an element and select security>lock. This will prevent admins from writing to the element but it would apply to all cubes.

Probably your best option, you could use rules to prevent access. For the Planning version, bring in actuals via a rule, then if the user tries to spread to the months containing actuals they can't, and if the user spreads to all months (consolidation) then the spread value will be split amongst the months that are available.

[orlando]

Hi,

in my opinion, you have two options.
- The users with admin rights need a second user (without admin rights) that is used for planning,
- You put the actual data on a separate data type and make a rule that writes the data of the actual months to the plan.
As an example (if you only have one plan year at the monthly level)
The months get the attribute (number) isActual
In the rule you now query the attribute.

['Plan'] = if('}ElementAttributes_Month', !Month, 'isActual') = 1, ['Actual'], continue);

Whether the rule is sufficient depends on the data model. The feeder then also depends on the final rule.

Many greetings
orlando

[Mark2007]

Hi Mark,

We had a similar issue and we decided to use the }Capabilities cube. Not sure if it will work for Admin

https://www.ibm.com/docs/en/planning-an ... ssignments

Take a look at Allow Spreading.

Also, not sure what you mean by "Web-application". Are you talking about TM1 Web Cube View, Perspective/Pax, Workspace, TM1 Application ?

Let me know if it works

Thanks for your quick response! With "Web Application" I mean a sheet (Application) in TM1Web.
I studied your reference to the manual. But as I do not want to disable the ADMIN from spreading in general, but only from prevent some of the months from being changed, I think the capabilities-cube will not work.

[Mark2007]

You can lock an element by going into the subset editor (legacy subset editor) and right clicking on an element and select security>lock. This will prevent admins from writing to the element but it would apply to all cubes.

Thanks for the good idea! I did not think about "lock" (or "reserve") - but I checked the security: Members of ADMIN-Group do automatically always have ADMIN-rights to all Dimensions and Elements and this cannot be changed.

Probably your best option, you could use rules to prevent access. For the Planning version, bring in actuals via a rule, then if the user tries to spread to the months containing actuals they can't, and if the user spreads to all months (consolidation) then the spread value will be split amongst the months that are available.

This will be the safest way in the long run. As I'll have to change the modell, I'll discuss this with the customer. Probably, I'll take the suggestion of Orlando (next post) and offer a second user to the ADMIN

[Mark2007]

Many, many thanks for your ideas! and many thanks for the speed you wrote back! The easiest way will be a second user for the Administrator. I'll discuss the solution with the planning department.

Regards

Mark

[orlando]

Many, many thanks for your ideas! and many thanks for the speed you wrote back! The easiest way will be a second user for the Administrator. I'll discuss the solution with the planning department.

Regards

Mark

The easiest way may be the second account, but the solution via the rules is more sustainable.
I would use the rules, even if the model then has to be modified.

Best regards,
orlando

[Steve Rowe]

Thanks for the good idea! I did not think about "lock" (or "reserve") - but I checked the security: Members of ADMIN-Group do automatically always have ADMIN-rights to all Dimensions and Elements and this cannot be changed.

Setting to LOCK will also stop admins from changing the data, it is a stricter level than READ / WRITE.

[Mark2007]

Thanks for the good idea! I did not think about "lock" (or "reserve") - but I checked the security: Members of ADMIN-Group do automatically always have ADMIN-rights to all Dimensions and Elements and this cannot be changed.

Setting to LOCK will also stop admins from changing the data, it is a stricter level than READ / WRITE.

But I did not manage to change security settings (Element Security) for the ADMIN-Group. Or do I miss something? By default, it's all "ADMIN" if I have a look to dimension security (Right click on Dimension => Security => ElementSecurity)
or it's an empty cell when I have a look in the cube }ElementSecurity_DimName, but when I enter something in cell }Groups:ADMIN / Element xyz, than TM1 replies: "not a number: LOCK"

[burnstripe]

The lock on an element is applied/stored within elementproperties not elementsecurity.

This article explains it well...
https://cubewise.com/blog/things-might- ... ty-part-2/

[Mark2007]

Thanks for this explanation - it's gonna work! Great!

the more as the LOCK can be sent via TI:
https://www.tm1forum.com/viewtopic.php?t=588

[Steve Rowe]

If you are going to use locking extensively and are combining that with TIs then you are probably also going to want to use CubeLockOverride(), a lightly documented TI function.
To turn all locking off in the whole DB use CubeLockOverride(1); To turn it back on again use CubeLockOverride(0);

Turning it back on again is somewhat redundant as it turns back on as if by magic when the TI finishes but its as well to us it to keep things tidy (and in case the magic ever stops happening....)

Cheers,