Troubleshooting
Problem
This tech note explains the way in which TM1 Applications ('TM1 Contributor' applications in some prior TM1 releases) are secured in TM1 10.2. It describes the way that cell-level security is now used to secure access to TM1 Applications, and explains how cell security interacts with any existing element security that may be in use in the model.
Symptom
Customers upgrading TM1 Applications from releases prior to TM1 10.2 may observe that element security set to the READ level no longer appears to take effect. This document explains why that is and how it can be resolved.
Resolving The Problem
Summary
The TM1 Application Server takes the Rights that the modeller specifies for an Application’s Approval Hierarchy and translates them into security objects in the TM1 Server. In TM1 10.1.1 and earlier, the TM1 Application Server enforced the Rights through the use of element security on the Approval Hierarchy dimension. One effect of this was that the Approval Hierarchy dimension was tied to that Application only.
In TM1 10.2, TM1 Applications have a new concept of a Control dimension; this is intended to delineate the scope of different Applications so that the Approval Hierarchy dimension can be re-used, and so that multiple Applications may be deployed against different slices of the same cube; for example, to have a Budget and a Forecast application that could be deployed and secured independently. In TM1 10.2, the TM1 Application Server takes the Rights for the Application and enforces them by using cell security on the cube(s) in the Application.
Use of cell security
In TM1 10.2, it is no longer necessary for a cell security cube to use all of the dimensions of the parent cube. When a cube is deployed in a TM1 Application, the TM1 Application Server will create a cell security cube (if none exists already) for that parent cube. The TM1 Application Server will create the cell security cube with the minimum necessary dimensionality; if the Application has both an Approval Hierarchy and a Control dimension specified, then the cell security cube will contain these two dimensions along with the }Groups dimension. The use of a Control dimension is optional; if no Control dimension is specified for the Application, then the cell security cube will just contain the Approval Hierarchy dimension and the }Groups dimension. By default, when an Application is upgraded from TM1 10.1.1 or earlier, no Control dimension will be specified. The modeller is permitted to open the cell security cube in Performance Modeler and supplement these dimensions with additional ones if they wish, by using the Change dimensionality button on the security editor toolbar.
If a cell security cube already exists for a given cube deployed in the TM1 Application, then the following action is taken:
- If the existing cell security cube had a rule applied, then the full dimensionality of the cell security cube will be retained, along with the existing rules. The TM1 Application Server will insert a new rule to enforce the application Rights at the top of the rule string for the cell security cube.
- If the existing cell security cube had no rule applied, then it will be destroyed and re-created with the minimum necessary dimensionality – i.e. just the Approval Hierarchy and Control dimensions, plus }Groups. Again, the TM1 Application Server will then insert a new rule to enforce the application Rights at the top of the rule string for the cell security cube. This is done for ease of modelling and to ensure the minimum memory footprint for the cell security cube. If you had an existing cell security cube that you had populated with hard string values (rather than using Rules), you should export and back up the cube data before proceeding with the upgrade.
In TM1 10.1.1 and earlier, the TM1 Application Server took control of element security for the Approval Hierarchy dimension. Once the upgrade to 10.2 is performed, any existing element security cube for the Approval Hierarchy dimension will be removed.
Once the cell security cube is in place (with the required dimensionality), the TM1 Application Server enforces the Approval Hierarchy Rights by writing a rule into the cell security cube that references a system cube that the TM1 Application Server uses to store details of the application Rights. The modeller should not attempt to delete or disable this Rule, but they are free to move it within the rule string (to get the correct Rule precedence) if they want to supplement cell security for other purposes; this is discussed further below.
Central applications
The concepts of an Approval Hierarchy and a Control dimension only apply to Approval and Responsibility applications. A Central application type has no Approval Hierarchy or Control dimension. When a Central application is created and deployed, no additional security objects are created; existing TM1 security (such as element security) will still take effect on cubes deployed in a Central application. The Rights for a Central application are enforced solely by determining which users can or cannot see the hyperlink to the Central application in the TM1 Applications portal.
Interaction of cell security and element security
The use of cell security to secure TM1 Applications offers greater freedom in terms of Application design. However, there are situations where it impacts the effect of existing element security.
Consider a situation where the modeller deploys a view of the plan_BudgetPlan cube in the Planning Sample database. The Application uses the plan_business_unit dimension as the Approval Hierarchy, and the plan_version dimension as the Control dimension:
The modeller also uses element security on the plan_time and plan_chart_of_accounts dimensions; for some elements in plan_time, Groups are granted READ access to make the data read-only, while for some elements in plan_chart_of_accounts, certain Groups are granted NONE access because they are not entitled to view data for certain accounts at all.
To recap, the Rights that define access to the Approval Hierarchy will be enforced by using cell security on the plan_BudgetPlan cube; by default the TM1 Application Server will create a cell security cube that has dimensions plan_business_unit, plan_version and }Groups. This use of cell security will not affect the use of element security on plan_chart_of_accounts – the NONE access applied there will ensure that the selected accounts will still be hidden from the relevant users.
Consider a specimen application where, Group 10100 has REVIEW rights to Europe. So when user Jones logs in, opens the UK node and takes ownership, Jones will only see a handful of child members below Other Expensesin plan_chart_of_accounts as some of the items have NONE security applied.
However, the READ security set on plan_time will not have the effect that it would have done in TM1 10.1.1 and earlier; this is because any user requiring SUBMIT, EDIT or REVIEW rights to a given combination of Approval Hierarchy node (in plan_business_unit) and plan_version (the Control dimension slice in this example) will be assigned WRITE security for their Group in the cell security cube. Because cell security (where it is specified - i.e. there is an entry in the cell security cube) overrides element security, the READ security set on plan_time will no longer take effect. For for example, cells for Jan-2004, Feb-2004 and Mar-2004 remain writeable even if element security on plan_timewould otherwise make them READ only. Looking at the cell security cube for plan_BudgetPlan for Group 10100 we see that this is because the rule that drives the assignment of Rights results in WRITE security for nodes 10100, 10110 and 10120 in plan_business_unit for all elements in plan_time.
Enforcing READ security
The modeller has a few choices to enforce a READ constraint in this situation, as follows:
- For an Application upgraded from TM1 10.1.1 or earlier, the modeller could add plan_time as the Control dimension, and then use the Control Dimension tab of the Rights page to ensure that the maximum rights that any user has are READ rights for Jan-2004, Feb-2004 and Mar-2004. The effect of setting READ against a member of the Control Dimension is to place a cap on the maximum security granted on that element when the Rights are translated into cell security; so even if user Jones in Group 10100 would have SUBMIT or EDIT access to the UK node in the Approval Hierachy (for example), setting access to an element in the Control Dimension to READ will ensure that Jones will only be able to READ that element.
This option is not recommended if you may wish later to use the Control dimension feature to deploy discrete applications for different Budget or Planning cycles – since you would most commonly use a version-style dimension to delineate those applications.
- Add the plan_time dimension to the cell security cube for plan_BudgetPlan, and use a Cube Calculation or a Rule to enforce the READ constraint that was previously enforced using element security on plan_time. One means of achieving this is to reference the }ElementSecurity_plan_time cube in a Cube Calculation or Rule in the }CellSecurity_plan_BudgetPlan cube. For example, if the plan_time dimension had an ActFcstFlag attribute that identified Actual periods to be made read-only, the additional rule could look like this (note that the DB() reference can simply be copied and pasted from the system-generated rule written by the TM1 Application Server):
[{'FY 2003 Budget','FY 2004 Budget'}] = S: IF(
(ATTRS('plan_time',!plan_time,'ActFcstFlag')@='Actual')
&
DB('}tp_intermediate_RDCLS}plan_BudgetPlan',!plan_business_unit,!plan_time,'all_applications',!}Groups,'StaticRights')@<>'',
'READ',
CONTINUE);
- If READ security was previously used to stop edits being made to Actual data, those Actuals could be stored in a separate Actual slice of the cube (or in a different cube), and then pulled into the writeable slice (that we intend end users to interact with) using a Rule. This will prevent any users changing the Actual data in the writeable slice. If the actual data are stored in an Actual slice of the same cube, that slice could be hidden using element security set to NONE; if the actual data are stored in a separate Actuals cube, the cube could be hidden from users with cube security.
Related Information
Was this topic helpful?
Document Information
Modified date:
15 June 2018
UID
swg21651554