View Issue Details

IDProjectCategoryView StatusLast Update
0020866mantisbtfilterspublic2016-06-12 00:42
ReporterlbayleAssigned Tocproensa 
PrioritynormalSeveritymajorReproducibilityalways
Status closedResolutionfixed 
Product Version1.3.0-rc.1 
Target Version1.3.0-rc.2Fixed in Version1.3.0-rc.2 
Summary0020866: Plugin Filters: Data Type mismatch.
Description

It seems like there's an unneccessary type check on filters that makes FILTER_TYPE_MULTI_STRING not working.

this might be a misunderstanding on creating filters, but I realy don't see what's wrong.

As attachment:

  • a simple filter plugin to show the bug
  • screenshot of the error
Steps To Reproduce

go to view_all_bug_page.php page
click on 'FilterSample'

Additional Information

I could make the plugin work by deactivating the type check in filter_api.php line 4090, 4094
=> add param to check_selected()

check_selected( $g_filter[$p_field_name], META_FILTER_ANY ), '>[', lang_get( 'any' ), ']</option>';

check_selected( $g_filter[$p_field_name], META_FILTER_ANY, false ), '>[', lang_get( 'any' ), ']</option>';

TagsNo tags attached.

Activities

lbayle

lbayle

2016-05-01 09:22

reporter  

FilterSample.zip (2,528 bytes)
lbayle

lbayle

2016-05-01 09:22

reporter  

filter_error.PNG (39,966 bytes)
filter_error.PNG (39,966 bytes)
cproensa

cproensa

2016-05-01 16:50

developer   ~0053048

I think the FILTER_TYPE_MULTI_STRING type for MantisColumn object is broken

cproensa

cproensa

2016-05-01 17:07

developer   ~0053049

Last edited: 2016-05-01 18:14

View 2 revisions

How should the FILTER_TYPE_MULTI_STRING work?

I think the expected behaviour as it's implemented is:
The filter exposes a set of strings, which are expected to be an array of key=>string.
this would allow to have a predefined set of options, like:

Array(
 1 => 'string 1',
 2 => 'string 2',
 etc
)

The filter stores the key value, and this key value is what should be checked against inside the MantisColumn object

There can be a more complex scenario, where the strings used in the filter are not part of a predefined set. This can happen if the options are dynamically generated, like lbayle exaple. In his sample filter, he is using bug summary text as "string" and bug id as "key".
But if there is not a clear key, one may need to use the string as key.

(1) This leads me to thinking: for this type of filter, keys should be treated as strings (even if they are integers)

(2) There is an issue with check_selected(), when it's used against an array of values. This case must be reworked, becasue one value may be contained in the array, but that does not mean that it should trigger an error for each other non-equal item in the array. edit: this is not an issue is the filter kays are treated consistently as strings

cproensa

cproensa

2016-05-01 18:55

developer   ~0053050

@lbayle, your plugin as is, should work for FILTER_TYPE_MULTI_INT type
However the error is detected for FILTER_TYPE_MULTI_STRING:
PR: https://github.com/mantisbt/mantisbt/pull/772

lbayle

lbayle

2016-05-02 03:16

reporter   ~0053051

Hi, thank you for your concern.
By the way, the plugin does not work with FILTER_TYPE_MULTI_INT

cproensa

cproensa

2016-05-02 05:28

developer   ~0053053

Yes, it does work as FILTER_TYPE_MULTI_INT.
You may get an error due to changing the type while still having a different type of value in your stored filter settings for user.
Change user, or modify the filter field name, to start clean.

cproensa

cproensa

2016-05-16 15:31

developer   ~0053157

fixed in current master
with commit f5a278d

Related Changesets

MantisBT: master f5a278d6

2016-05-01 18:09:03

cproensa


Committer: vboctor Details Diff
Fix FILTER_TYPE_MULTI_STRING type for plugin filter

When treating filter options keys as strings, META_FILTER_ANY has to
be used as a string, to not trigger a type mismatch error

Also, when using check_selected() to print selected options, "strict"
option cannot be used because not always the option keys can be kept
as strings.
This happens when the options returned by the plugin filter object
uses integers for keys. Even if the keys are set as string type, PHP
will translate them to integer keys, thus triggering a type mismatch
error if strict check is used.

Eg:
array( '1' => 'x' ) is parsed by PHP as:
array( 1 => 'x' )
mod - core/filter_api.php Diff File

Issue History

Date Modified Username Field Change
2016-05-01 09:22 lbayle New Issue
2016-05-01 09:22 lbayle File Added: FilterSample.zip
2016-05-01 09:22 lbayle File Added: filter_error.PNG
2016-05-01 16:50 cproensa Assigned To => cproensa
2016-05-01 16:50 cproensa Status new => confirmed
2016-05-01 16:50 cproensa Note Added: 0053048
2016-05-01 17:07 cproensa Note Added: 0053049
2016-05-01 18:14 cproensa Note Edited: 0053049 View Revisions
2016-05-01 18:55 cproensa Note Added: 0053050
2016-05-02 03:16 lbayle Note Added: 0053051
2016-05-02 05:28 cproensa Note Added: 0053053
2016-05-16 15:31 cproensa Status confirmed => resolved
2016-05-16 15:31 cproensa Resolution open => fixed
2016-05-16 15:31 cproensa Fixed in Version => 1.3.0-rc.2
2016-05-16 15:31 cproensa Note Added: 0053157
2016-05-16 15:31 cproensa Target Version => 1.3.0-rc.2
2016-05-16 18:00 cproensa Changeset attached => MantisBT master f5a278d6
2016-06-12 00:42 vboctor Status resolved => closed