Projects:Grid Configuration
Contents |
Overview
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:
- Non sortable/filterable grid columns
- Grid filter by "starts with" or "equals"
- Apply filters configuration
Detailed information for these 3 cases can be found in the next sections of this document.
Non sortable/filterable grid columns
Purpose
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.
Configuration
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:
- Tab level: defines the default behavior for the fields in the tab. It is defined by 2 boolean fields: "Can sort" and "Can filter". In case there is no row in this table for a given tab, this will have current behavior (filtering and sorting allowed for all columns).
- Field level: For fields in the tab it will be possible to define 2 behaviors: "Filter" and "Sort". For these 2 fields one of these values can be chosen:
- "Tab Default": The field will have the same behavior for that option as the one defined in the tab. In case no row for a given field is present "Tab Default" will be taken for it.
- "Yes": Regardless tab default, the field will be sortable or filterable.
- "No": Regardless tab default, the field will not be sortable or filterable.
UI
Smart Client's default UI will be used for these settings.
- Non-filterable fields are shown as disabled in filter bar. See example.
- Non-sortable fields. The only visual hint is the mouse cursor changes from clickable to no clickable icon.
Technical considerations
- Cache
- 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.
- Adaptive
- 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"
Purpose
Default mechanism of filtering consists in looking for text containing anywhere the entered value regardless its case (upper/lower).
Configuration
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.
UI
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.
- Cache
- 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
Purpose
Two problems to address:
- Currently filtering is applied while typing. This can cause several requests to be launched for a single filter. For example if filtering for "John Smith", depending on how fast the user types different partial request could be performed: "J", "Joh", "John Sm"...
- It is not possible to wait for user confirmation to apply all the filters and sorting. If user wants to filter by 2 fields, requests for each of them are executed.
Configuration
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 data is initially requested when the tab is opened
- User confirmation is required to apply filters/sorting
UI
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:
- Disabled: current filters are applied
- Enabled: user has modified filters or sorting but they have not yet been applied, requiring user to click on it to apply them.
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:
- ADRD dataset: currently implemented for some tables such as Country. It is applied once when instance is created.
- New kind of "Defaults" dataset: It would be possible to create new datests of this kind, they would be applied when the instance is created or when a module that includes a new one is installed.
In any case this is out of the scope of this project.
Screenshots
