Implementing filters

The UI filters are disabled for the custom data source API connection in Flexmonster by default. You can choose which filters to enable in Flexmonster and support on the back end. This filter configuration can be done in the schema and the filtering itself should be implemented in the query.filter part of the /select request. 

The guide focuses on how to configure filters. Filters can be:

• Turned on all at once
• Configured separately for fields of a certain type
• Defined for each field individually

Available filter configurations

There are three properties in the /fields request through which filters can be configured:

• members (optional) – Boolean. Configures an include/exclude members filter. If true, the members filter is enabled in Flexmonster Pivot.
• query (optional) – Boolean|Array of strings. Configures a conditional filter on members. This filter can be turned on either by setting the property to true or by specifying an array of supported conditions.
  If this property is set to true, it enables all the conditions that exist in Flexmonster Pivot for the members filter. See the list of supported conditions for “string”, “number”, and “date” field types.
• valueQuery (optional) – Boolean|Array of strings. Configures a conditional filter on values. This filter can be turned on either by setting the property to true or by specifying an array of supported conditions.
  If this property is set to true, it enables all the conditions that exist in Flexmonster for the values filter. See the list of supported conditions.

These configurations can be applied to all fields, to fields of a certain type, and/or to certain fields.

Turn on all filters at once

Turning on all filters at once is the simplest way to enable filtering. To enable all available filters, set the root filters property of the /fields request to true:

"filters": true,

This approach requires implementing all the available filters in Flexmonster Pivot (see the list of supported filters).

Configure filters for fields of a certain type

It is possible to specify the supported filtering conditions for fields of a certain type. This can be done in the root filters property of the /fields request.

Filters for any field type

Filters that are common for all the field types can be defined by specifying the filters.any property:

"filters": {
    "any": {
        "members": true,
        "query": ["equal", "not_equal"],
        "valueQuery": ["top","bottom"]
    }
} 

Here, the query property can contain only "equal", "not_equal", "between", and "not_between" conditions since these are the only conditions that are common for all the field types.

In the valueQuery property, you can specify which conditions are supported by the filter on values.

Filters for fields of a certain type

The string, number, and date properties allow you to configure filters for fields of a corresponding type. Here is an example of filters configuration for the "string" field type:

"filters": {
    "string": {
        "members": true,
        "query": ["equal", "not_equal"],
        "valueQuery": ["top", "bottom"]
    }
}

Here, the query property can contain conditions that are supported by the “string” field type.

In the valueQuery property, you can specify which conditions are supported by the filter on values.

Filters for the fields of the "number" and "date" types can be configured similarly. See the list of supported conditions for “number” and “date” field types.

Define filters for individual fields

Filters can also be configured for individual fields. This can be done by specifying the fields.filters property:

"fields": [{
    //other properties
    "filters": {
        "members": true,
        "query": ["equal", "not_equal"],
        "valueQuery": ["top", "bottom"]
    }
}],

In the valueQuery property, you can specify which conditions are supported by the filter on values.

Conditions that can be defined in the query property depend on the field’s type. See the list of supported conditions for “string”, “number”, and “date” field types.

Supported filtering conditions

Conditions for the filter on values

Conditions for the filter on values are common for all field types. The supported conditions are the following: "top", "bottom", "equal", "not_equal", "greater", "greater_equal", "less", "less_equal", "between", "not_between".

For the members filter, the supported conditions depend on the field type. Have a look at the list of supported conditions for “string”, “number”, and “date” fields below.

Conditions for the “string” field type

The filter on members supports the following conditions for the "string" field type: "equal", "not_equal", "begin", "not_begin", "end", "not_end", "contain", "not_contain", "greater", "greater_equal", "less", "less_equal", "between", "not_between".

Conditions for the “number” field type

The filter on members supports the following conditions for the "number" field type:  "equal", "not_equal", "greater", "greater_equal", "less", "less_equal", "between", "not_between".

Conditions for the “date” field type

The filter on members supports the following conditions for the "date" field type: "equal", "not_equal", "before", "before_equal", "after", "after_equal", "between", "not_between", "last", "current", "next".

After configuring the filters in the schema, the handling of the query.filter part of the /select request should be implemented.

Note that the server always receives either "between" or "not_between" in the filtering request when Flexmonster Pivot uses the following date filters:

• "equal"
• "not_equal"
• "last"
• "current"
• "next"

To use these date filters on the client, implement the "between" and "not_between" filters on the server.

What’s next?

You may be interested in the following articles:

• Implementing the custom data source API server
• Returning data for the drill-through view
• Supporting more aggregation functions
• Supporting multilevel hierarchies