View Issue Details

IDProjectCategoryView StatusLast Update
0013937mantisbtfilterspublic2014-12-08 00:34
Reporterdregad Assigned Todregad  
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version1.2.8 
Target Version1.3.0-beta.1Fixed in Version1.3.0-beta.1 
Summary0013937: 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

  • Define a filter on Product Version "V" and apply it
  • Update that filter by clicking on Product Version
  • Nothing is selected (Version "V" should be selected)
TagsNo tags attached.

Relationships

related to 0013935 closeddregad Version based filtering not possible 
related to 0007995 closedzakman Confusion in product_version values due to string comparisons with == operator 
related to 0011124 closeddhx The 'sticky_issues' value stored in the mantis_filter_table is not always stored correctly. 

Activities

atrol

atrol

2012-02-22 04:38

developer   ~0031290

Last edited: 2012-02-22 04:38

Same wrong behaviour for field category (not for other enums)
Maybe the same cause.

dregad

dregad

2012-02-22 05:46

developer   ~0031291

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.

dregad

dregad

2012-02-23 18:25

developer   ~0031306

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.

dhx

dhx

2012-02-24 05:22

reporter   ~0031308

Last edited: 2012-02-24 05:22

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

dhx

dhx

2012-02-24 11:12

reporter   ~0031312

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).

dregad

dregad

2012-02-24 11:42

developer   ~0031313

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 !).

dregad

dregad

2012-02-27 09:37

developer   ~0031335

Keeping this one opened for now, until decision has been taken to backport to 1.2.x (or not).

atrol

atrol

2013-08-16 12:50

developer   ~0037893

Changed assignment. dhx will not contribute to this issue in near future.

dregad

dregad

2013-10-21 18:37

developer   ~0038324

With 1.3.x making good progress towards release, I see no reason to keep this as a target for 1.2.

govind

govind

2013-12-01 22:04

reporter   ~0038698

sdfgdf

govind

govind

2013-12-01 22:05

reporter   ~0038743

xdfjghjgh

Related Changesets

MantisBT: master 1f515b3a

2012-02-23 22:15

dhx


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

dhx


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