Unable to filter using custom fields after upgrade

[t3knoid]

I recently upgraded from 1.0 to 1.1.7. I've worked out some upgrade issues on my own except for one that is baffling me. I am using custom fields. Before the upgrade I was able to filter searches (View Issues) using these fields. After upgrading to 1.1.7, the filter still works for records that have not been changed after the upgrade. It also does not work with new bugs.

Does anyone have a clue as to why this is happening? Thanks.

[t3knoid]

I've looked into this further....I am using a "Multiselection list" custom field. Each selection is delimited by a '|' and apparently the older version of Mantis (1.0.6) stores the string in the mantis_custom_field_string_table with the "|" on each end of the string. For example if you have an entry such as the following:

AA|AB|AC|AD

The entry AB is stored as |AB| in the mantis_custom_field_string_table. Now with 1.1.7, the string is stored correctly as AB. The odd thing is that the filter fails with this entry but works if I put back the entry as |AB|.

I am working on a solution and will share it here when I find one.

[t3knoid]

I've figured out a workaround for my specific issue. I edited two core files so that the filter will work with the old entries (the ones with "|" around it) and new entries.

around line 1210 of core/filter_api.php, modify the line:

array_push( $t_filter_array , db_helper_like( "$t_table_name.value", '%|' . db_prepare_string( $t_filter_member ) . '|%' ) );

to

array_push( $t_filter_array , db_helper_like( "$t_table_name.value", db_prepare_string( $t_filter_member ) ) );

This will remove the two "|" around the custom field value

after line 16 of database_api.php add the following line:

$p_value = '%' . $p_value . '%';

This will change the MySQL statement so that LIKE finds the substring of the custom field value. Doing so will allow the filter to see the values |AA| and AA as the same and therefore show up in the search.

This may not work for all, but it works fine for my purposes.

[jonnieboy]

I hit this problem too on 1.1.8 (having upgraded from 1.1.1), thanks for posting your fix, really helped me out!!

I fixed it in a slightly different way as I was a bit concerned about changing db_helper_like() as it is used elsewhere and I wasn't sure of the consequences. So I went with:

filter_api.php#1210

From:

Code: Select all

array_push( $t_filter_array , db_helper_like( "$t_table_name.value", '%|' . db_prepare_string( $t_filter_member ) . '|%' ) );

To:

Code: Select all

array_push( $t_filter_array , db_helper_like( "$t_table_name.value", '%' . db_prepare_string( $t_filter_member ) . '%' ) );

This (and I think the original suggestion too) does have the problem that you may get more matches than you expected e.g. if your multiselection list allows "1.1", "1.1.2", "1.2" etc the database may contain values like "1.1.2" or "1.2|1.1.2" (new) or "|1.1.2|" or "|1.2|1.1.2|" (old). Filtering on "1.1" would (I expect), match all of these but it should match none of them. For me that isn't an issue because of the way our multiselection lists are defined.