Skip to main content

Pentaho+ documentation is moving!

The new product documentation portal is here. Check it out now at


Hitachi Vantara Lumada and Pentaho Documentation


pentaho.config.spec. IRuleSet

The config.spec.IRuleSet interface describes a list of configuration rules used to configure one or more types.

The following example is a hypothetical configuration, where a developer (John) states that only he should see the visualization he is currently developing (my/radial/bar) and only then when working in Pentaho Analyzer:

var myTypeConfig = {
  rules: [
    // Disable a still experimental Viz.
      select: {
        type: "my/radial/bar"
      apply: {
        isBrowsable: false

    // Enable it, only for the dev user, "john", when in Analyzer
      select: {
        type:        "my/radial/bar",
        user:        "john",
        application: "pentaho/analyzer"
      apply: {
        isBrowsable: true

Rule Selection

A rule is selected by a given type and environment variables, if the type and variables match the rule's selection variables.

Rule Specificity

Rule specificity is a measure of the relevance of a rule.

When two or more selected rules configure the same specification attribute, it is the value used by the most specific rule that wins. When configured values are structural and are instead merged, like with an Object value, specificity determines the order in the merge operation (most specific is merged over less specific).

A rule is more specific than another if it:

  1. has a greater priority; this is the attribute that most affects specificity, and can be used to easily surpass every other affecting factors,
  2. selects a user (and the other doesn't),
  3. selects a theme (and the other doesn't),
  4. selects a locale (and the other doesn't),
  5. selects an application (and the other doesn't),
  6. belongs to a rule set that was added later, or
  7. it is at a greater index within a rule set.

Rule's Configuration Merging

Type configuration rules specify a configuration in its apply property.

When merging two configurations, the default behavior works this way:

  1. If both configurations contain a plain JavaScript object, in the same property, the two are deeply merged
  2. All other values, such as arrays, null, undefined or objects of custom classes, are replaced.

To allow overriding the default merge behavior, the following object syntax is supported in the place where any value would be:

  fruits: {
    $op:   "add"
    value: ["banana", "apple"]

In the previous example, the "add" operation is used to append new elements to an existing array configuration value, instead of replacing it, as is the default.

In the following example, the "replace" operation is used to replace an object configuration value, instead of merging it, as is the default:

  score: {
    $op:   "replace"
    value: {"banana": 1, "apple": 3, "orange": 2}

Note that replacing with a Nully value effectively clears existing configurations.

Source: doc-js/pentaho/config/spec/IRuleSet.jsdoc, line 17

See also: pentaho.config.IService


Name Description
contextId :  string

The context module identifier to which module and dependency identifiers are relative and that determines any applicable AMD/RequireJS module mappings.

rules :  pentaho.config.spec.IRule

The list of configuration rules.

Members Details

contextId:  string

The context module identifier to which module and dependency identifiers are relative and that determines any applicable AMD/RequireJS module mappings.

When unspecified and the rule set is registered and loaded from a module, this property defaults to that module's identifier.

Source: doc-js/pentaho/config/spec/IRuleSet.jsdoc, line 129

See also: pentaho.config.spec.IRule#deps

rules:  pentaho.config.spec.IRule

The list of configuration rules.

Within a type configuration, if all other rule ordering criteria are equal, the later configuration rules override the former configuration rules.

Source: doc-js/pentaho/config/spec/IRuleSet.jsdoc, line 143