You can set the method that is used to determine how rights to a cube or cell are enforced by an application. There the way rights are enforced when an application shares an approval hierarchy has changed.
Before TM1 version 10.2, an approval hierarchy could not be shared across an application. Rights to view or edit a particular piece of data were enforced with element security on the approval hierarchy. In TM1 version 10.2, the architecture was changed so that rights are enforced with cell security. This change meant the approval hierarchy dimension could be used in multiple applications. It also enabled multiple Applications to be deployed from the same cube.
Method to enforce rights is a parameter that determines the technique that is used to enforce rights.
To share an Approval Hierarchy dimension across TM1 Applications, you need to use cell security to enforce rights. With cell security, a Control Dimension is used to delineate the Applications. When Cell Security is used, the TM1 Application Server creates Cell Security cubes for all data cubes in the Application that contains the Approval Hierarchy dimension. If Cell Security cubes already exist, the TM1 Application Server extends their dimensionality to ensure that they include the Approval Hierarchy dimension and the Control Dimension if a control dimension is used.
When rights are enforced with element security, the element security is populated on the Approval Hierarchy dimension using a TurboIntegrator process. In that case, a change to the rights does not generate a Security Refresh.
You cannot use a Control Dimension if Element Security is used to enforce the rights.
In TM1 version 10.2.2, you can use the Enforce Element Security on Approval Hierarchies parameter to turn Element Security on for approval hierarchies. This parameter is a property of all the Approval or Responsibility Applications for a given TM1 server.
Enforce Element Security on Approval Hierarchies defaults to Yes for both new and upgraded environments.
To be sure that any user in any non-TM1 Application interface, for example TM1 Web, Architect, or Cognos Business Intelligence (BI), sees only approval hierarchy dimension elements for which they have access, set this parameter to Yes. Remember that the user can have access to more than one Application. The Yes setting applies Element security to any dimension used as an approval hierarchy.
In the.earlier releases 10.2 GA and 10.2 FP1, element security was not applied to the approval hierarchy dimension. In that case, if you use Architect, for example, you can see all the elements of the Approval Hierarchy in the subset editor, even though you can see the data for only the elements for which you have rights in the TM1 Application.
If rights are enforced using Cell security, then Element Security is applied to the Approval Hierarchy dimension only if the Enforce Element Security on Approval Hierarchies option is set to Yes. When Enforce Element Security on Approval Hierarchies is yes, element security is applied using a rule that refers to a control cube maintained by the TM1 Application Server. This cube contains logic that computes the aggregate security across all Groups and all Applications that use the same Approval Hierarchy dimension. In this case, because Element Security is driven using Rules, the TM1 Application Server must do a Security Refresh when the Rights are updated. This Security Refresh can take some time for a large TM1 Server. If this time is prohibitive, you can revert to using Element Security to enforce Rights, or switch the Enforce Element Security on Approval Hierarchies option to No.using a Control Dimension is not possible if Element Security is used to enforce the rights.
When Cell Security is used as the Method to enforce Rights, then you can additionally set a parameter added in TM1 version 10.2.2 called CELLSECURITYMOSTRESTRICTIVE in the }CubeSecurityProperties cube, for the data cubes in the scope of the Application.
When CELLSECURITYMOSTRESTRICTIVE is yes, Element and Cell Security behave such that the most restrictive applies. For instance, if Element Security for a specific element is set to READ for a given Group and Cell Security for a cell referencing that dimension element is set to WRITE, then security will resolve to READ. If the CELLSECURITYMOSTRESTRICTIVE parameter is set to any value other than YES, then the server behaves as it did in the prior releases.
Choosing how to set this parameter depends whether you wish to take advantage of the new behavior when CELLSECURITYMOSTRESTRICTIVE is set to yes, or whether you wish to maintain the existing TM1 Server behavior. If you have existing TM1 Applications built using TM1 10.1.1 or earlier that use Cell Security, you are likely to want to retain the old behavior, so the CELLSECURITYMOSTRESTRICTIVE parameter need not be altered. If you are building new Applications in TM1 10.2.2, you wish to use the ability to share Approval Hierarchy dimensions, and you want to make use of READ-level Element Security on some dimensions, then you can set CELLSECURITYMOSTRESTRICTIVE to yes to have your Element Security respected.
If you already have Applications deployed in TM1 10.2, you may have used the techniques described in the IBM Technote 'Element Security and TM1 Applications in TM1 10.2 http://www-01.ibm.com/support/docview.wss?uid=swg21659499.
The use of the CELLSECURITYMOSTRESTRICTIVE parameter will allow you to model some of the scenarios described in that Technote more easily.
The TM1 Application Server does not access CELLSECURITYMOSTRESTRICTIVE and it is blank by default. This behavior means that in the TM1 Server, Cell Security set to WRITE overrides READ-level Element Security, which is the behavior used in earlier releases. If you wish to enforce rights using Cell Security, for example, to share Approval Hierarchies, and you also wish to use Element Security set to READ, then set this parameter to YES for the relevant cubes.