From the feedback I received so far, the new Mondrian role feeding system seems to work pretty well. There was only one tiny bit missing: Mondrian reacts absolutely unhappy, if it encounters roles it cannot understand. If your roles come from a external source, like LDAP, you usually have more roles there as are defined in Mondrian. Even in a standalone, all in-memory solution, the platform roles very likely form a super-set of the defined Mondrian roles. To make Mondrian happy without too much manual work (or heaven forbid: work on every report-definition), we now have a role-filtering system for both the OLAP4J and Mondrian datasources. The filter is a classical deny-then-accept filter usually found in firewalls. You can remove known bad roles and you can have a known good roles list. All the filter-rules are enabled via the global config stored in the famous "classic-engine.properties" file. For the BI-Server, this file can be found in the "pentaho/WEB-INF/classes" directory. For the Pentaho Report Designer, the file is in the "resources" directory.

# Enables or disables the filter code. Is disabled by default. org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.enable=true

Filtering is controlled via 4 sets of properties. Deny wins over accept. You can either filter by static comparison or via reg-exp matching. There can be multiple keys per category, just make the "name" at the end unique. This greatly helps with long-term maintenance as a 10.000 chars regexp is no fun to edit each time someone adds or removes a role. In case there is no accept rule in your configuration, a default accept-all rule gets active.

org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.reg-exp.accept.<name>=*rolename* org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.reg-exp.deny.<name>=*regexp suitable for String.matches(..)* org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.static.accept.<name>=*rolename* org.pentaho.reporting.engine.classic.extensions.datasources.mondrian.role-filter.static.deny.<name>=*regexp suitable for String.matches(..)*

Filtering is only active, if the role is read from a field, and if the value read is an array. You can use the "env::roles-array" safely to read the roles from the server and the filter rules will make sure that Mondrian is happy too. The mapping between environment names and data-row names (and as side-effect, the definition whether a environment property can be interpreted as array) can also be defined in the global configuration. The following code snipplet shows the default configuration.

# # Defines, which environment properties are published as fields in a report. The mapping is a # environment-name to data-row column name mapping. # # Any environment property name that ends with "-array" will be read without the "-array" suffix # and will be interpreted as CSV string that can be parsed into an array of strings. org.pentaho.reporting.engine.classic.core.env-mapping.serverBaseURL=env\:\:serverBaseURL org.pentaho.reporting.engine.classic.core.env-mapping.pentahoBaseURL=env\:\:pentahoBaseURL org.pentaho.reporting.engine.classic.core.env-mapping.solutionRoot=env\:\:solutionRoot org.pentaho.reporting.engine.classic.core.env-mapping.hostColonPort=env\:\:hostColonPort org.pentaho.reporting.engine.classic.core.env-mapping.username=env\:\:username org.pentaho.reporting.engine.classic.core.env-mapping.roles=env\:\:roles # # The roles-array env-key is a virtual key. This returns the roles as parsed string-array. org.pentaho.reporting.engine.classic.core.env-mapping.roles-array=env\:\:roles-array

Properties from the Server's session can be accessed via session::attribute-name. The value stored in the HTTP-Session must be a String. Example: if you have a string stored by the name magic-attribute, then you can access that string via the environment property name session::magic-attribute.