View Issue Details

IDProjectCategoryView StatusLast Update
0020866mantisbtfilterspublic2016-06-12 00:42
Reporterlbayle Assigned 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.
Attached Files
FilterSample.zip (2,528 bytes)
filter_error.PNG (39,966 bytes)   
filter_error.PNG (39,966 bytes)   

Activities

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

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:
<pre>
Array(
1 => 'string 1',
2 => 'string 2',
etc
)
</pre>
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 14:09

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' )
Affected Issues
0020866
mod - core/filter_api.php Diff File