View Issue Details

IDProjectCategoryView StatusLast Update
0035291mantisbtfilterspublic2025-02-04 08:10
Reporterchadmiss Assigned To 
PrioritynormalSeveritymajorReproducibilityalways
Status confirmedResolutionopen 
Product Version2.25.7 
Target Version2.27.1 
Summary0035291: Filters including date custom fields don't work on PHP 8.0
Description

wie did a version bump from 2.25.2 to 2.25.7 and now none of the filters on view_all_bug_page are working.

I boiled it down to a custom-field that appears in the filter_string in filters_table. that custom-field is a date and in the database its value for the filter is ["","1","1"]. that is a very old custom-field and in virtually every filters present. I found out that fixing the value to ["0","1","1"] brings the filters back to work.

I am just not sure if this is the correct solution or if this is a bug on our end (we've been using Mantis with version bumping for the past 15 years. yikes!)

TagsNo tags attached.

Activities

dregad

dregad

2025-02-03 13:06

developer   ~0069816

It's not clear what you mean by none of the filters on view_all_bug_page are working - can you be more specific ? Error message ? Unexpected behavior ?

["","1","1"] is not a normal, valid value for a date filter, the first entry should be a number. For a custom field of type date.["0","1","1"] means any. So you should be safe with the mentioned update (assuming that you indeed want your filter not to include a criteria for your date custom field).

I did not check, but It is possible that in some ancient MantisBT version, "any" was stored as null, hence the entries in your filters table. Can you confirm that those records are for the latest version (filter_string column should start with v9#).

It may also be super useful, if you know how to do that, to run a git bisect between release-2.25.2 and release-2.25.7 tags, to identify the commit which introduced the regression for you.

dregad

dregad

2025-02-03 13:39

developer   ~0069817

Last edited: 2025-02-03 13:40

I tried updating a test saved filter showing all assigned issues with SQL to have ["","1","1"] for a date custom field, and I can confirm that there is unwanted behaviour:

In the filters grid, instead of showing any, the custom field is it's just an empty string (see screenshot), and there are no Issues returned (there should have been 3). This is with PHP 8.2.

If I run the exact same test with PHP 7.4, I get the expected behavior (i.e. mydate field filter shows any and the 3 Issues are listed).

And all this is regardless of MantisBT version: tried with 2.25.2, 2.25.7 and master, same results.

So, what is your PHP version ?

image.png (9,729 bytes)   
image.png (9,729 bytes)   
chadmiss

chadmiss

2025-02-04 03:23

reporter   ~0069818

sorry about the missed info.
we also updated PHP from 7.x to 8.1.2
"filters not working" means that the result is empty. not tickets seem to be found

so I guess it is because of the PHP update.

Said customfield is one of the oldest we still have in use. So this really seems so be an ancient relic. I think we will do a string-replacement in the Database to fix this value

thanks for the reply!

dregad

dregad

2025-02-04 05:31

developer   ~0069819

we also updated PHP from 7.x to 8.1.2

That's it then.

I think it will be difficult and probably not worth the effort to identify the root cause, i.e. why your filters are stored as ["","1","1"] instead of ["0","1","1"], but as you mention this can be easily fixed with a SQL update as a workaround.

I'll investigate what is causing the date filter to fail when the type is '' (empty string) instead of the expected integer, as it sounds like a regression introduced by PHP 8.x.

As a side note, why limit your upgrade to 2.25.7 and not a more recent MantisBT release ? I strongly recommend upgrading at least to 2.26.4 to address several security issues and benefit from improved PHP 8.x support (especially considering that you are now on 8.1.2). Note that 2.27.0 has a few known issues, 2.27.1 should be released soon.

dregad

dregad

2025-02-04 08:10

developer   ~0069820

OK, I nailed it. The problem comes from this check in BugFilterQuery::build_prop_custom_fields() at line 1470:

            # Skip date custom fields with value of "any", these have a special array format
            if( $t_def['type'] == CUSTOM_FIELD_TYPE_DATE && $t_field[0] == CUSTOM_FIELD_DATE_ANY ) {
                continue;
            }

In PHP <= 7.x, $t_field[0] == CUSTOM_FIELD_DATE_ANY evaluates to true when $t_field[0] == is an empty string, but starting with PHP 8.0 it returns false as a consequence of implementing this RFC: https://wiki.php.net/rfc/string_to_number_comparison. As stated:

This change to the semantics of non-strict comparisons is backwards incompatible. Worse, it constitutes a silent change in core language semantics. Code that worked one way in PHP 7.4 will work differently in PHP 8.0.

And so it hit us (you) ;-)