View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0021031||mantisbt||filters||public||2016-05-31 10:24||2017-01-31 04:02|
|Priority||normal||Severity||minor||Reproducibility||have not tried|
|Target Version||2.1.0||Fixed in Version||2.1.0|
|Summary||0021031: Rewrite the filter box form|
I am cleaning up code in filter api, and we know the filter box table is a mess. Its code is very difficult to mantain and has some rendering issues.
At this point, it's easier for me to rewrite the whole table-generating code, than trying to fix the inconsistencies.
Use this issue to discuss the requirements if there is any.
|Tags||No tags attached.|
|related to||0019700||closed||cproensa||Filters table on the view_all_bug_page.php shows empty lines when $g_enable_profiles is set to OFF|
|related to||0017852||closed||cproensa||Tags is showing on its own row in filter box|
|related to||0018045||closed||cproensa||Changed ordering of fields on View Issues page|
|related to||0014709||closed||cproensa||In the filter page, the customized fields are resets without any reason|
|related to||0004771||new||"Use Date filter" does not work with loclized date_format|
|related to||0021032||closed||cproensa||Setting $g_filter_custom_fields_per_row to other than default can cause empty cells in filter box|
|related to||0016854||new||Simplify the filter box at the top of the View Issues page|
|child of||0021935||closed||cproensa||Filter api refactoring, manage stored filters|
My current proposal is:
Keep the filter box similar to how it currently exists, but generate it with a cleaner code, which can be more easily mantained.
The generation code would work like this:
1) For each fields, create each filter cell separately, and build later the table adding each field sequentially.
2) The plugin fields, and custom fields, would have their rows separated from standard fields. Then having 3 sections:
3) Review $g_filter_custom_fields_per_row. This config is inconsistent with the rest of the table having a different cell count.
4) Some fields are wider. This algorith is easy to adapt to have filter cells that have colspan>1, using a greedy allocation.
5) With this code, it would be much easier to enhance with a customizable field ordering, or limit which fields are shown by some kind of configuration
probably related to 0016854
Even if we dont change how the filters are implemented at this moment, this work helps in modularizing the field presentation.
The filter code is really hard to maintain and there are quite a lot of known bugs in it, so +1 in general.
Given the complexity of the filtering space and the scope of this, I wouldn't want this to be in v1.3.
I would rather go to a model like 0016854 or starting from an empty filter and adding elements one at a time.
The user clicks + and adds a query row with the fields they want to filter on.
I suggest we close this as duplicate of 0016854 and have the discussion there.
Victor, i'm not sure this is really a duplicate
There is no breaking change on the filter UI, nor the filter structure.
So summarizing what i want to do here, as UI-look-and-feel is affected:
Work in progress in PR 862
Resolving this as part of merge of PR 988.
Further discussion on improvements in filter presentation should go into 0016854