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.

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)   

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!

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.

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

PR https://github.com/mantisbt/mantisbt/pull/2105

@chadmiss if you get a chance to test the pull request in the next couple of days, your feedback would be much appreciated.