View Issue Details

IDProjectCategoryView StatusLast Update
0020883mantisbtfilterspublic2016-10-25 18:41
Reportercproensa Assigned To 
PrioritynormalSeverityminorReproducibilityhave not tried
Status newResolutionopen 
Summary0020883: Request: remove filter view type
Description

This is a request for, as part of a possible filter redesign, removing the view_type (simple/advanced) feature as it is now.

The usefulness of advanced view is to select multiple values from the possible values offered by the filter.
Being a global switch for the filter, it has some drawbacks:

  • Probably the advanced feature is only wanted by the user for only one, or a limited set, of fields. Having to deal with all fields in the advanced behaviour can be cumbersome.
  • The UI can get cluttered easily.

Additionally, the view mode flag seems to be a property that is carried on the request parameters, and not stored in the filter by itself.
This causes issues for already stored filter fields values, when changing view mode, where those values may be inconsistent, or are not translated properly for the new context.

Ideally, the simple/advanced behaviour should be tied to each field, and stored as part of the filter, as a field property alongside the stored values.

The configuration options for: default_simple, default_advanced, simple_only, etc...
I don't think they are that much relevant. Seeing view modes as a feature, it should not be a problem to be: "simple" by default, "advanced" available for all users.

TagsNo tags attached.

Relationships

related to 0016854 new Simplify the filter box at the top of the View Issues page 

Activities

cproensa

cproensa

2016-10-25 18:41

developer   ~0054344

I wonder if including this in the "filter sanitization" PR 862...

I'd really like to get rid of the simple/advanced difference in filters
As fas as i know, the "view type" affects filters in some ways:

  • Simple mode uses single-selection inputs for some fields (those that can be multivalues), whereas advanced mode uses multiple selection inputs
  • Simple mode shows the filter "hide status", (which only has sense when status is set to "any"). This field is not used in advanced mode.
  • Advanced mode shows the field "project"
  • Simple mode will get bugs from current project and subprojects, whereas advanced mode, when any project id is selected, does not search within subprojects.

My proposal to remove this simple/advanced modes implies:

1) simple or multiple selection input is always available (for supported fields), and the user can choose to have a given field in multiple selection mode if requested
This can be achieved with javascript, if each field features an expand icon (resembles the collapse feature), where the field input is switched between a single dropdown and a multiselect list.

2) All fields are shown. This means "hide_status" and "project" are always useable and not treated differently from other fields.

3) "show_status" and "hide_status" are combined and as one single visible field. This can be presented as a two alternatives selection

  • either: show status (single or multiple status ids)
  • or: hide this status and above (single status id selection)

4) A new property is added to indicate "search_subprojects", which instructs the filter whether to include subprojects of selected projects. This is presented as a secondary checkbox within the "project" field.

This changes has some consequences:

A) Filter relies in javascript capabitilies. The switching of filter fields between single and multiple cant be made in a friendly way with static pages.

B) Remove configuration "view_filters", which can be:
SIMPLE_ONLY, ADVANCED_ONLY, SIMPLE_DEFAULT, ADVANCED_DEFAULT
Note: this has been proven to not being already working correctly in some cases.
Simple_default & advanced_default seems like they would be superseeded by proposed functionality, as they were propably intended for convenience.
Simple_only, probably was intended to avoid having the users overwhelmend with complex filters
Advanced_default, i'm not sure if there is actually a use case that justifies having this option.

This will provide a more homogeneus filter treatment, as the behaviour of filter fields and values is definied with the data contained by the filter itself (in contrast, at presen, filter behavioir changes based on view-type)
Also, will improve reliability of permalinks, which already have some problems related to this.