View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0020866||mantisbt||filters||public||2016-05-01 09:22||2016-06-12 00:42|
|Target Version||1.3.0-rc.2||Fixed in Version||1.3.0-rc.2|
|Summary||0020866: Plugin Filters: Data Type mismatch.|
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.
|Steps To Reproduce|
go to view_all_bug_page.php page
I could make the plugin work by deactivating the type check in filter_api.php line 4090, 4094
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>';
|Tags||No tags attached.|
FilterSample.zip (2,528 bytes)
filter_error.PNG (39,966 bytes)
filter_error.PNG (39,966 bytes)
I think the FILTER_TYPE_MULTI_STRING type for MantisColumn object is broken
How should the FILTER_TYPE_MULTI_STRING work?
I think the expected behaviour as it's implemented is:
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".
(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
Hi, thank you for your concern.
Yes, it does work as FILTER_TYPE_MULTI_INT.
fixed in current master
MantisBT: master f5a278d6
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
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.
array( '1' => 'x' ) is parsed by PHP as:
array( 1 => 'x' )
|mod - core/filter_api.php||Diff File|
|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|