View Issue Details

IDProjectCategoryView StatusLast Update
0021031mantisbtfilterspublic2017-01-31 04:02
Reportercproensa Assigned Tocproensa  
PrioritynormalSeverityminorReproducibilityhave not tried
Status closedResolutionfixed 
Product Version1.3.0-rc.2 
Target Version2.1.0Fixed in Version2.1.0 
Summary0021031: 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.

TagsNo tags attached.


related to 0019700 closedcproensa Filters table on the view_all_bug_page.php shows empty lines when $g_enable_profiles is set to OFF 
related to 0017852 closedcproensa Tags is showing on its own row in filter box 
related to 0018045 closedcproensa Changed ordering of fields on View Issues page 
related to 0014709 closedcproensa 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 closedcproensa 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 closedcproensa Filter api refactoring, manage stored filters 




2016-05-31 11:29

developer   ~0053239

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.
This would avoid having gaps when some fields are disabled by configuration (or access level).

2) The plugin fields, and custom fields, would have their rows separated from standard fields. Then having 3 sections:

  • standard bug fields
  • plugin + custom fields
  • Filter specific fields: sort by, match type, highlight, search
    A "section" means that if no more fields are to be shown, a space is inserted until next row.

3) Review $g_filter_custom_fields_per_row. This config is inconsistent with the rest of the table having a different cell count.
We can either, deprecate it, and create a more general $g_filter_fields_per_row, that applies to all table... or render the custom fields in a different table body which would effectively have a different cell count without breaking the layout.

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



2016-05-31 15:27

developer   ~0053242

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.
With less effort, another iteration can be done to rethink the javascript and dynamic filter system, so a cleaner approach can be implemented.



2016-06-01 02:39

developer   ~0053243

The filter code is really hard to maintain and there are quite a lot of known bugs in it, so +1 in general.

To consider

  • introduces even more delay to get out 1.3
  • questionable effort if the plan is to implement 0016854 in a future version
  • introduces additional work to keep modern ui [1] up to date

[1] 0017919



2016-06-01 03:35

manager   ~0053244

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.

  • assigned: me
  • status: < resolved.

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.



2016-06-01 06:26

developer   ~0053245

Victor, i'm not sure this is really a duplicate
This comes as part of this PR:

There is no breaking change on the filter UI, nor the filter structure.
For the proposal at 0016854, i'm sure a change in filter structure wil be needed, like currently we have no precise way to know which filter fields has been modified.

So summarizing what i want to do here, as UI-look-and-feel is affected:

  • Place the filter fields sequentially, to avoid empty cells.
  • But some fields can be kept as separated groups, like: put the custom fields on their own row... (this is current behaviour)
  • No other change to the current UI, or html behind the form.

Note that:
This would be done on top of PR:783, so target it to whatever that one goes.



2016-10-17 17:20

developer   ~0054258

Work in progress in PR 862



2017-01-14 17:29

developer   ~0055124

Resolving this as part of merge of PR 988.

Further discussion on improvements in filter presentation should go into 0016854