Managing User Access using CDL

Control access to widgets or pages and data-level access in widgets by defining table references, user properties, hierarchy filters, and access rules.

Defining Table References

Control user access to widgets or pages and data-level access in widgets by defining table references, user properties, hierarchy filters, access rules.

Table references can then be added in the Config Hub code block:

table accessRules = AccessRules.AccessRules

Assigning Table Columns to User Properties

These additional properties can now be associated as user properties through a user property claim in the config hub code block.

  userProperty claim #Role {// adds a new value on @currentUser object that we can refer to later e.g. in filter
    joinKey: accessRules:UserName// username to match on currently logged in user
    value: accessRules:Role// which corresponding column value we want to use
  }
  userProperty claim #Node {
    joinKey: accessRules:UserName
    value: accessRules:Node
  }

Now that these properties are defined, we can use them for controlling access.

Setting User Access Nodes within Hierarchy Filters

To control data-level access, we use the end-user’s node assignment within the hierarchy filter definition. There are two properties we can set:

• Setting the root property sets the top-level access node visible in the hierarchy filter. If no root property is specified then the end-user can navigate/filter any part of the full hierarchy.

• Setting the default property sets the default selected node of the hierarchy when the end-user initially logs in. the end-user is then still allowed to navigate to / filter any branch within the full hierarchy up to and including the node specified in the root property.

  filter hierarchy {
    label: "Regional Stores Hierarchy"
    hierarchy: storesHier:12345
    optionLabel: storesHier:language_text
    smartExpand: true
    //role based permissions
    default: @currentUser.Node
    root: @currentUser.Node
  }

Properties available for @currentUser:

emailaddress	Email address
name	User Name
givenname	First Name
surname	Surname

This can be referred to in CDL to display information about the user who is logged in. For example in a headline widget as below:

widget headline #headlineWidget {

    label: "Information on current user"

    tile value #valueTile {

      value: @currentUser.name

    }

    tile value #valueTile_2 {

      value: @currentUser.givenname

    }

    tile value #valueTile_3 {

      value: @currentUser.surname

    }

    tile value #valueTile_4 {

      value: @currentUser.emailaddress

    }

  }

Using Access Rules to Control User Access to Widgets or Pages

To control access at the page or widget level based on a user’s defined role, we use an access rules code block within the page or widget. Using an access rules property means that the page will show when the rules criteria are met.

Within the access rules code block, we add a rule claim property for every property-based condition that needs to be met for the widget to be shown.

page #regionalView {
  access rules {
    rule claim {
      name: "Role"
      value: "Regional Manager"
    }
  }
  label: "Regional View"
}
page #storeView {
  access rules {
    rule claim {
      name: "Role"
      value: "Store Manager"
    }
  }
  label: "Store View"
}

Multiple values may be specified on the same rule with comma-separated values, for example having a rules claim with

Value: “Store Manager”, “Regional Manager”

Means that this page can be accessed by end users with a role of either “Store Manager” or “Regional Manager”.

When using multiple rule claims, ALL conditions must be met to access the page. For example in the example below, the end user must have a role of Store Manager AND be assigned to the US hierarchy node:

page #activity {
  access rules {
    rule claim {
      name: "Role"
      value: "Store Manager"
    }
    rule claim {
      name: "Node"
      value: "US"
    }
  }