Projects:Disable Default Field Filtering and Sorting/Specs
Contents |
Overview
When working in environments with high volumes of data, certain columns cannot perform correctly for sorting and filtering actions. These columns should be, by default, defined as non sortable nor filterable.
A typical example of this case is computed columns. Because they are not persisted in database, filtering and sorting actions on them will always require a full scan to calculate all their values before being possible to apply filtering or sorting.
Current status
Currently (3.0PR15Q4), it is possible to prevent sorting and filtering using Grid Configuration at System, Tab or field level.
Limitations
Grid configuration is designed to be applied as instance data, not being possible to define different configurations at the same level.
This approach has two caveats:
- It is not to be possible to define as part of source data how a column/field should behave (as to add these restrictions a grid configuration should be defined at instance level).
- If Grid Configurations are packaged within modules as reference data, when installing more than one of them, data will clash in case more than one configuration is defined for the same level. Example: module A defines grid configuration for Sales Order window preventing sorting but not filtering; module B defines grid configuration restricting both filtering and sorting for Sales Order window; when trying to install both modules together, the process will fail because of these two configurations conflicting for Sales Order window.
Solution
The two problems defined in previous section can be solved by the following two new extensions to the model.
Prevent sorting and filtering at column level (source data)
Columns would have two new boolean fields: Allow Filtering and Allow Sorting .
When flagged, any field based on this column would be filterable and/or sortable. Default value for existing data would be true, in this manner system would behave as currently (allowing both actions) for all existing fields.
When not checked, all fields based on this column will not be filterable and/or sortable. This default behavior can be changed only by defining a grid configuration at field level for these concrete fields. If there is a grid configuration at tab level and there is not a grid configuration at field level (or it is set as default) and if the value of the grid configuration at tab level is more restrictive than the value set at column level, the behavior set in the grid configuration at tab level will prevail. The same will happen with grid configuration at system level, it will overwrite the value defined at column level only if it is more restrictive and there is no grid configuration defined at tab or field level, or is set as default.
Adding this new flag at column level is preferred over doing at field level because:
- It is easier to configure: defining it at column level is automatically spread to any field based on that column.
- The most common case is to want to prevent it for all fields based on the same column, regardless in which window they are.
- In case of the need of allowing filtering and sorting for a concrete field in a concrete window whereas the rest of fields for the same column remain as not filterable and sortable, it is still possible by adding a grid configuration for it.
Allow more than one Grid Configuration at same level
In order to allow more than one Grid Configuration at the same level (System, Tab and Field) and prevent possible clashes in case of different modules defining them. A new field (Sequence Number) will be added to Grid Configuration at System and Tab levels.
Behavior would be:
- Only one configuration is applied per level, as it is now.
- In case of more than one configuration defined for the same level, only the one with the highest priority will be taken.
- In case of more than one configuration defined for the same level with the same sequence number, homogeneous behavior will be ensured by sorting also by grid config UUID, additionally a warning message should be logged.
- Configurations defined at field level are only applied in case their parent Tab configuration is applicable. This is the reason of not requiring sequence number at field level. This approach has been selected to simplify configuration.
Implicit filters for Grid Configuration at System and Tab levels should be created, so only applicable configurations are listed by default.
Existing configurations will be defaulted with a sequence number 100.
Open topics
Default sorting/filtering for new columns
Currently, all new columns are sortable and filterable by default. It needs to be defined which should be the default setting for filtering and sorting for new columns:
- Not allowed: if we choose to disable it, developers should always decide case by case which are the columns that should be allowed. In this manner they would be aware of it and they should test they behave correctly. This would be, though, an important change in the way new columns are developed.
- Allowed: there would be no change in the defaults. It would be responsibility of the developers to disallow it. There would not be change in the current development process but the risk would be developers to forget about this setting.
In any case, defaults for existing columns will be to allow both, in order to keep backwards compatibility.
Default sorting/filtering for new columns
The default behavior for the sorting and filtering properties of the new columns has been let as it was till now, that is, sortable and filterable by default.