IBM Planning Analytics (PA) allows administrator (admin) users to control users’ read and write access through different levels of object security. The system provides a set of redefined groups for admin purposes but allows custom groups to be created as well that users can belong to. Planning Analytics admins commonly use security controls to limit users’ access to elements within a dimension. This can be done by setting a security group’s access to READ, WRITE or NONE and then assigning specific users as members to these defined groups. However, manually creating security groups can be time consuming and require upkeep in the future.

Here we will describe a technique using PA rules on element security control cubes to make security maintenance much more efficient by applying security access only to the children (or grandchildren) of a specific element.

This approach will only require security groups to be set up for the parent element, one for READ access and one for WRITE access. A rule is written to give READ or WRITE access to these defined groups using the ‘ELISANC’ function, by looking at the children of a specified consolidation. Once the rule is in place, this security method will make life easier by automatically granting the correct security access based on the hierarchy structure.

Example Use Case

We will illustrate this technique using an example on a Location dimension. In this example, the business requirement is that anyone who has security access to a specific geographic region, should automatically have access to all locations within that region, including to new locations that are added as the business grows.

Step 1: Create Alternate Hierarchy

Alternate hierarchies can be implemented by a TurboIntegrator (TI) process or manually. They allow users to see alternate rollups of data in the cube. For example, the Location dimension above has a main hierarchy that shows locations rolled up by city to country and countries rolled up to a ‘Total Location’ element. The ‘Total Location’ hierarchy does not allow us to see the United States (US) data rolled up individually by states. Without this information (as if an attribute does not exist), we are not able to set security by state because the elements have no defining characteristics to link them to a state. Creating the ‘United States of America’ alternate hierarchy’s rollup shows all US cities as children of their respective states. Since this company’s headquarters and most of its offices are in New York state (NYS), we will implement a security rule for all offices in the cities within NYS. Although this hierarchy was generated from a TI process, an alternate hierarchy can also be created manually by copying and pasting elements in the Dimension Editor.

Step 2: Create New Security Group

We will introduce the convention that security group names will reflect the access they permit: “R” will represent read access and “W” will represent write access which will be attached to the group name. As an example, we will create two security groups for the New York State hierarchy, one for read access and one for write access. We will call the read group “LOCATIONR_NYS” and the write group “LOCATIONW_NYS”. Below we walk through the steps of manually adding security groups via Planning Analytics, but another way to add groups in PA is through the TI function ‘ADDGROUP’ with syntax of ADDGROUP(‘Group Name’). Here’s a link for some PA TI functions that may come in handy when dealing with security: https://www.ibm.com/docs/en/planning-analytics/2.0.0?topic=tf-security-turbointegrator-functions.

  1. To add a new security group in Architect right click on the server > Security > Clients/Groups to open the TM1 Clients/Groups dialog box

  1. Group > Add New Group to manually add the new security groups

  1. The new groups in this example are ‘LOCATIONW_NYS’ (write group) and ‘LOCATIONR_NYS’ (read group). When done adding new groups, always scroll to the right of the interface to make sure the groups have successfully been created then click “OK”.

Step 3: Assign Group’s Privileges

Now that the security groups have been created on the server, security rights need to be assigned to each group to grant users of the groups access that aligns with the “W” and “R” naming conventions. Read access granted to a group allows users of the group see data but not modify it, as write access enables modification by users. In this case we want all children of the ‘New York’ element to have READ and WRITE access granted to the “R” and “W” groups, respectively. We could now manually set the access to the children of ‘New York’ to READ and WRITE, but instead we will write a Planning Analytics rule attached to the ‘}ElementSecurity_Location’ cube that will automate it for us.

The ‘}ElementSecurity_Location’ control cube is a 2-dimensional cube consisting of an intersection between the location dimension and groups dimension which allows us to assign groups access to specific elements in the location dimension. The cube can be found in the server explorer as a control object which will only be auto generated if changes have been made to security of the location dimension. If the ‘}ElementSecurity_Location’ cube does not already exist, you can make a change in the “Elements Security Assignments…” to auto generate the cube or simply use the code provided below to create the cube through the ‘CUBECREATE’ TI function.

  1. Right click on ‘}ElementSecurity_Location’ cube and create/edit rule…

  1. The below PA rules will assign the correct privileges to the groups if the element is a child of the ‘New York’ hierarchy by using ‘IF’ statements. The rule looks for the READ and WRITE groups we created above by a ‘SUBST’function and then assigns read or write access according to group name to all elements that have ‘New York’ as their ancestor. Although the ‘ELISPAR’ ’ TI function would work here as well, ‘ELISANC’ will guarantee that if another level is added to this hierarchy in the future such as regions of the state, the leaf level elements will still be picked up. (Ex: New York > Western New York > Buffalo, New York is an ancestor of Buffalo, but New York is not Buffalo’s parent)

  1. We can double check the }ElementSecurity_Location cube to make sure the rules are populating access correctly. As we see below, these groups only have READ or WRITE access to children of the ‘New York’ roll-up element.

Step 4: Assign Users to Groups

With the groups created and their security privileges in place, users can be added to these groups through the }ClientGroups cube. This cube is 2 dimensions, one being the  }Clients and the other being the }Groups, which allows us to easily assign users while maintaining a familiar cube view of rows and columns intersections.

1. Open the }ClientGroups cube and chose the }Client element you’d like to assign to the groups, and the }Group you’re assigning

2. Remove zero suppression and assign specified client to a group by typing in the group name at intersection of the relative group and client. For example, we will add Sal to the “LOCATIONW_NYS” group by typing “LOCATIONW_NYS” at the intersection of “LOCATIONW_NYS” and Sal in the cube view.

  1. We now need to Refresh Security so the system can pick up on the adjustments we’ve made. We will do this by right clicking on the sever > Security > Refresh Security

  1. To verify results, sign in as a test user (Sal) that is assigned to one of the groups (LOCATIONW_NYS). In the Subset Editor for the Location dimension, Sal will only be able to view elements that have New York as their ancestor. If we open a cube view with the Location dimension, Sal can only see and write to data of cities of New York.

If a TurboIntegrator process is in place to define the ‘New York’ hierarchy, a simple execution of the TI process and Security Refresh will update the security groups’ rights to elements via our security method in the same step. If the ‘New York’ hierarchy is maintained manually, the cities will need to be copied from the main hierarchy and pasted as children of ‘New York’, then a Security Refresh is needed to regenerate our methodology. Having a Planning Analytics rule as the above in place, makes things security simple if we’d like to apply the same privileges for each state. That is, only giving “LOCATIONW_STATE” groups write access to the cities of the state in question. The rule can simply be added onto by adjusting by state name in the groups and location element lookups and of course, refreshing security!

Ask QueBIT

Want to discuss how best to perform other prototyping and development tasks within the PAW interface? Have a different question? You can always reach out to QueBIT at support@quebit.com for assistance. We’re here to help!