View source | View content page | Page history | Printable version   

Projects:Grid Configuration



The aim of this project is to provide a series of optional settings to be applied in grid in order to improve its performance when filtering and sorting.

Currently it is possible to sort and filter by any column in the grid, when filtering it always works as iContains (this is, it seeks text at any place not taking into account upper/lower case), furthermore filters are applied while the user is typing. Though this is very useful from a user point of view, due to database limitations, in some occasions, regarding volume of data, it cannot perform because indexes cannot be used. The settings proposed in this project try to address this problem by limiting grid sorting and filtering capabilities.

There are 3 new configurations:

Detailed information for these 3 cases can be found in the next sections of this document.

Non sortable/filterable grid columns


The purpose of this setting is to define some grid columns (it can be defined at field in tab level) to be non filterable or non sortable.

This configuration will be done at instance level, so in case troubles with default configuration, which allows sorting and filtering by any column, are found, it will be possible to set the instance not to allow it for some cases.


It must be configured at instance level, being the owner of this configuration not Openbravo but the instance owner.

Configuration is done through two new tables:


Smart Client's default UI will be used for these settings.

Technical considerations

This new configuration will be needed to be taken into account for view cache.
Delete cascade
To warranty data consistency, column in FK DB for this new configuration will be on delete cascade.
Columns non filterable/sortable will behave in the same way even with small datasets that would allow in client (adaptive) filtering and sorting. This decision is taken in order to make it consistent and prevent technical difficulties when, for example, filters and sorting are saved with a small dataset and later on data for the same conditions becomes bigger.

Grid filter by "starts with" or "equals"


Default mechanism of filtering consists in looking for text containing anywhere the entered value regardless its case (upper/lower).


Configured at instance level, not part of Openbravo source data.

Configuration is done through a new table that allows to define per field the way it will be filtered: iContains, iStartsWith, iEquals, Contains, StartsWith or Equals.


No special hint about the way the field is filtered is provided.

Technical considerations

Other criteria
Regardless the way the field configuration, other criterion can be used if the expression is typed.
This new configuration will be needed to be taken into account for view cache.
Delete cascade
To warranty data consistency, column in FK DB for this new configuration will be on delete cascade.

Apply filters configuration


Two problems to address:


Configuration option to describe filter behavior on fields

It is possible to define the time threshold before launching requests when typing in the filter.

If this threshold is -1, filter won't be applied till user presses enter or blurs the field.

To be configured through preferences so it will be possible to define at different levels (system, window...)

Wait for filters before requesting data

Defined per instance at tab level by a new flag.

When this flag is active:


No visual hint is provided for filtering threshold.

A new button appears in those tabs which filters are applied by user confirmation. This button has two states:

Additionally, when no data is shown when the tab is opened a new text in the grid should be shown, something like No data displayed. Apply filters and [link]confirm[/link] to request data.

General Considerations

Default Data

All these new settings should be defined at instance level, meaning they are not provided by Openbravo as source data.

It should be possible, though, to provide default configurations that are deployed for new instances but subsequent instance modifications are preserved and not modified by new updates, this could be achieved following two approaches:

In any case this is out of the scope of this project.





Retrieved from ""

This page has been accessed 5,438 times. This page was last modified on 19 November 2013, at 18:39. Content is available under Creative Commons Attribution-ShareAlike 2.5 Spain License.