The UI filters are disabled for the custom data source API connection in Flexmonster by default. You can decide which filters to enable in Flexmonster and support on the backend. 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 is focused on how to configure filters. The 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 the filters can be configured:

• members (optional) – Boolean. A configuration of an include/exclude members filter. If true, the members filter is enabled in Flexmonster Pivot.
• query (optional) – Boolean|Array of strings. A configuration of 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 the property is set to true, this 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. A configuration of 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 the property is set to true, this 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 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,

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

Configure filters for fields of a certain type

There is an option to specify 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

Define the filters common for all the field types 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 only these conditions are common for all the field types.

In the valueQuery property, you can specify conditions supported for the filter on values.

Filters for fields of a certain type

string, number, and date properties allow configuring 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 supported for the “string” field type.

In the valueQuery property, you can specify conditions supported for the filter on values.

In a similar way, filters for the fields of "number" and "date" types can be configured. 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. In 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 conditions supported for 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. Supported conditions are the following: "top", "bottom", "equal", "not_equal", "greater", "greater_equal", "less", "less_equal", "between", "not_between".

For the members filter, supported conditions depend on the field type. Find 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, handling of the query.filter part of the /select request should be implemented.

Note: 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 "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
• A quick overview of the sample Node.js server
• A quick overview of the sample .NET Core server