Dodeca has built in support for Role definitions. Once roles are defined, you can assign users to roles and allow role specific functions in your Dodeca application. With the assignment of roles, you can do things like:
· Allow access to applications
· Control which Hierarchies are available to users
· Allow access to Views within common hierarchies
· Allow actions within workbook scripts based on roles
In this post we will run through an example of the second item in the above list. We will perform the following tasks for a sample Dodeca application:
1. Create 2 new roles: Planner and Reviewer
2. Create 2 new hierarchies: Plan and Review
3. Within the USER application, align the roles with the corresponding hierarchy.
Anyone who opens the application with the role of Reviewer will see the Review hierarchy, and anyone with the role of Planner will see the Plan hierarchy.
The OUTLOOK Application.
As the Admin, I have created the OUTLOOK Tenant and it has an ADMIN and a USER application. It is a simple forecasting application based on the Sample Basic Essbase application that allows the company to build forecasts throughout the year. The difference with Sample Basic is I have added a dimension for Years and have added additional scenarios to represent the forecast called Outlooks.
Here is a look at the View Hierarchy and opening View in the ADMIN application. There are 13 views.
There are different functions in this application to performed by specific individuals.
A Reviewer can:
- Perform scenario maintenance such as: open and seed a scenario for data input, close a scenario and publish a scenario back to the Reporting Cube.
- Review input from Planners
- Accept or Reject the forecast from the Planners
- See all reports
A Planner can:
- Enter data on input forms.
- See some reports.
For our simple example, the activities translate into what can be performed in the Views. We can control the activities of each role by controlling what views are available to each role. Here is the list of View and the corresponding access by Role:
Roles are defined within your Tenant. That is, they are available for use across any number of Applications defined in your Tenant. In the OUTLOOK tenant, we have an ADMIN application and a USER application. The roles and hierarchies in this example will apply to the USER application.
To define roles for the Tenant, go to User Roles under the Admin menu:
This will open the User Roles metadata editor.
We will create two new roles for this OUTLOOK Tenant: Planner and Reviewer. Click on the New button at the bottom of the editor to create the roles.
Now we have two defined roles, REVIEWER and PLANNER.
Next, we will create two new Hierarchies. Go to the Hierarchies metadata editor from the Admin menu.
We currently only have the Standard Hierarchy, which we can see below. We are going to create two new Hierarchies, and we will call them Review and Plan. Hierarchies require and ID and a Name.
Once committed, the hierarchies will appear in alphabetical order, like this:
Next, we can edit the Hierarchies to insert views and categories per the Access grid above. Once the Views and Categories have been added to the hierarchies they will look like this:
Great. We now have the roles and hierarchies defined. Our next step is to edit the USER application to set up the Role to Hierarchy mapping.
Open the Application metadata editor under the Admin menu, and click on the USER application:
The first property we need to update is under the Security category. Update the AuthenticationServiceObjectTypeID to DodecaUserRoles.
Next check the properties under the View Selector category. Under ViewSelector Properties, there is a HierarchyToRoleMapping property.
Click on the ellipsis on the far right to open the Hierarchy to Role mapping dialog box. We set the mapping as:
And save the application.
We have a couple of test users for this application. Andy Dwyer is a Planner, and Leslie Knope is a Reviewer. We can assign their roles in the User Manager in Dodeca:
All done! Let’s test the application for Andy:
We see that Andy has the correct Hierarchy for a Planner. Now let’s check Leslie:
Yep, Leslie has the correct hierarchy for a Reviewer. Voila! All set!