Access Control File Samples

In this example, the default setting allows this folder to have the same access control rules as the parent folder.

access {
  inherit-from-parent-folder
}

NOTE: The inherit-from-parent-folder tag cannot be used at the project root level as there is no parent folder to inherit from.

In this example, all users are allowed to read files in this folder, but only user Burt can write to them.

access {
  file-access {
    allow-read 
    allow-write {
     if-user "Burt"
    }
  }
}

In this example, the property Function with the value Manager is used to allow users with this property and value to view the Profit column.

access {
  cbase-access {

    restrict-columns "Profit"
    allow-columns "Profit" {
      if-property "Function" "Manager"
    }
  }
}

NOTE: You can use only one restrict-columns tag within a cbase-acceess tag. Multiple allow-columns tags are allowed so you can allow access to restricted columns for specific users, groups, or those with a certain property applied.

In this example, an expression is used to create a union of two different rules.

cbase-access {
    limit-rows-by-filter {
      filter ```
      user_property_contains("pfm-fac-id", value("Facility ID"))    or
      user_property_contains("pfm-gac-dep-id", value("Facility Code-Dept ID"))
      ```
    }
  }

In this example, an expression is used to simulate wild card values of 10* and 20* by taking a two character substring of the value in "Sales Manager Code" and comparing that value to the numbers 10 and 20.

cbase-access {
    limit-rows-by-filter {

      filter `is_in(substr(value("Sales Manager Code"), 1, 2), "10", "20")`
    }
  }

The following scripts shows two alternatives for controlling access to the data by user. The first script controls access to rows by user by using the current_user function with a filter limit. The second script uses the username limit for the same purpose.

  // To control access to rows by user, use the current_user function with a filter limit.
  cbase-access {
    limit-rows-by-filter { 
      filter `value("Dimension") = current_user()`
    }
  }  
  // To control access to rows by user, use the username limit.
  cbase-access {
    limit-rows-by-username-column {
      column "Dimension"
    }
  }

In this example, a manager property and a flag on financial data is used to limit access. The following will grant access to everything if "Financials" does not contain "True" and will restrict on the Regional Manager Property if "Financials" does contain "True":

cbase-access {
  limit-rows-by-filter {
    filter ```(value("Financials")="True" and 
     user_property_contains("Regional Manager Property",value("Regional Manager")))
     or value("Financials")!="True"```
  }
}

In this example, the sales region data is limited for the Managers group. This is for a classic Model in a Workbench project.

access { 

  model-access {
    limit-dimension {
      if-group "Managers"
      dimension "Sales Region"
      values "New England" "Mid-Atlantic" "South East"
    }

}

In this example, the audit block contains two trigger declarations and two additional columns to log, in addition to the trigger dimensions.

access {
  audit-rules {
    audit {
      trigger "Patient Name"
      trigger "MRN"
      column "Address"
      column "Diagnosis"
    }
  }
}

Project access, at the root level, defaults to inherit-from-parent-folder. When you refine the access using Tools > Server Settings > Projects > Project Access and grant access to a non-administrative user or group, or set allow-all-users, the access control data for the project access is stored in a text file at:

<dataroot>\config\projects\<projectname>\project-access-config.sdl

This file is in SDL format, not tab delimited. Occasionally, you might want to update the contents with an Integrator or other type of script.

In the following example, access to the project is limited to two users and one group.

project-access {
  allow-user "frank"
  allow-user "lisa"
  allow-group "Managers"
}