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 |
Reporter | lbayle | Assigned To | cproensa | ||
Priority | normal | Severity | major | Reproducibility | always |
Status | closed | Resolution | fixed | ||
Product Version | 1.3.0-rc.1 | ||||
Target Version | 1.3.0-rc.2 | Fixed in Version | 1.3.0-rc.2 | ||
Summary | 0020866: 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:
| ||||
Steps To Reproduce | go to view_all_bug_page.php page | ||||
Additional Information | 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. | ||||
Attached Files | |||||
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: 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 |
|
@lbayle, your plugin as is, should work for FILTER_TYPE_MULTI_INT type |
|
Hi, thank you for your concern. |
|
Yes, it does work as FILTER_TYPE_MULTI_INT. |
|
fixed in current master |
|
MantisBT: master f5a278d6 2016-05-01 14:09 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 |