View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0013937 | mantisbt | filters | public | 2012-02-21 19:03 | 2014-12-08 00:34 |
| Reporter | dregad | Assigned To | dregad | ||
| Priority | normal | Severity | minor | Reproducibility | always |
| Status | closed | Resolution | fixed | ||
| Product Version | 1.2.8 | ||||
| Target Version | 1.3.0-beta.1 | Fixed in Version | 1.3.0-beta.1 | ||
| Summary | 0013937: Versions and Categories from existing filter not preselected when editing it | ||||
| Description | While debugging 0013935, I noticed a flaw with the version filters: the current 1.2.x code (including 1.2.8) is not pre-selecting the values from the current filter in the list when updating it. As per atrol's comment 0013937:0031290, the same problem exists for Categories. | ||||
| Steps To Reproduce | Assume a version "V" exists
| ||||
| Tags | No tags attached. | ||||
| related to | 0013935 | closed | dregad | Version based filtering not possible |
| related to | 0007995 | closed | zakman | Confusion in product_version values due to string comparisons with == operator |
| related to | 0011124 | closed | dhx | The 'sticky_issues' value stored in the mantis_filter_table is not always stored correctly. |
|
Same wrong behaviour for field category (not for other enums) |
|
|
It's quite possible. I already have a fix for versions lined up, but was waiting for your feedback on 0013935 before pushing it as it's touching the same section of the code; I'll see if the same logic can be applied also for Categories. |
|
|
The fix is here for now: https://github.com/dregad/mantisbt/tree/fix-13937 I did not push it to the main repo, because there is a problem when (one of) the selected version(s) is a string: in this case the value [any] always and incorrectly gets pre-selected. I believe this is due to a bug in check_selected() function as described here https://github.com/mantisbt/mantisbt/commit/9fbbd86e5f4087d062a15cda07726bc924bc6ec6#commitcomment-1004835 I'll wait for dhx's feedback. |
|
|
This very early commit from 5 September 2007 (referencing bug 0007995) is highly relevant as it is the last time check_selected() changed in a meaningful way: https://github.com/mantisbt/mantisbt/commit/ab391ab469ce1b3d37b6bb4f299c11c6271e50ef |
|
|
I just pushed some fixes to the master branch to solve this problem. I'd appreciate if someone is able to double check my extensive testing to make sure I didn't miss anything. The next step is to backport these patches to master-1.2.x (not an easy job unfortunately). |
|
|
Many thanks dhx. You may go to bed now ;) I will have a look and perform tests next week. Will also evaluate whether it's worth back-porting to 1.2.x or not, based on complexity of your changes (15 files, wow !). |
|
|
Keeping this one opened for now, until decision has been taken to backport to 1.2.x (or not). |
|
|
Changed assignment. dhx will not contribute to this issue in near future. |
|
|
With 1.3.x making good progress towards release, I see no reason to keep this as a target for 1.2. |
|
|
sdfgdf |
|
|
xdfjghjgh |
|
|
MantisBT: master 1f515b3a 2012-02-23 22:15 Details Diff |
Fix 0013937: Filter dropdown values of [any], [none], etc not saved Damien Regad <damien.regad@merckgroup.com> and Roland Becker <roland@atrol.de> reported an issue whereby filter dropdowns would always select the meta filter option of [any] by default, even if the active filter was set to another value. The cause is incorrect logic within both the check_checked and check_selected functions dating back to issue 0007995 in 2007. Documentation has been added inline to the code to clarify how these functions work and the gotcha to do with == vs. === comparisons. |
Affected Issues 0007995, 0013937 |
|
| mod - core/helper_api.php | Diff File | ||
|
MantisBT: master 79c04ca2 2012-02-24 03:02 Details Diff |
Fix 0013937: Fix check_selected and check_checked functions These functions were originally designed very loosely with respect to input data types. This was causing problems in numerous areas where strings were being compared with integers, etc. Both functions have been modified such that an error will be generated when the types are inconsistent. This will force developers to properly consider the types of variables when coding with MantisBT, ensuring less likelihood of bugs arising from "1.1"=="1.10", 0=="" comparisons, etc. Most if not all elements of the UI with drop-down boxes, check boxes, radio boxes and lists have been thoroughly tested after these changes. The default state of these UI fields should once again match default configuration values in config_inc.php, current values of the field/filter, etc. This greatly improves the usability of the UI. |
Affected Issues 0013937 |
|
| mod - account_prefs_inc.php | Diff File | ||
| mod - bug_report_page.php | Diff File | ||
| mod - bug_update_advanced_page.php | Diff File | ||
| mod - core/filter_api.php | Diff File | ||
| mod - core/helper_api.php | Diff File | ||
| mod - core/html_api.php | Diff File | ||
| mod - core/plugin_api.php | Diff File | ||
| mod - core/print_api.php | Diff File | ||
| mod - core/profile_api.php | Diff File | ||
| mod - manage_custom_field_edit_page.php | Diff File | ||
| mod - manage_proj_cat_edit_page.php | Diff File | ||
| mod - manage_proj_edit_page.php | Diff File | ||
| mod - manage_user_edit_page.php | Diff File | ||
| mod - tag_update_page.php | Diff File | ||