View Issue Details

IDProjectCategoryView StatusLast Update
0022653mantisbtfilterspublic2017-04-16 19:47
Reporteratrol Assigned Tocproensa  
Status closedResolutionfixed 
Product Version2.3.0 
Target Version2.3.1Fixed in Version2.3.1 
Summary0022653: Regression: Filter by date broken

Filter by Date Submitted and Filter by Last Updated Date does not work any longer (2.2.3 worked).

View Issuespage does not deliver any issues if a date filter is set.

TagsNo tags attached.


related to 0008957 assignedsyncguru Date Selector for Custom Fields 
related to 0022663 closedsyncguru APPLICATION ERROR 1303 Non-mandatory date custom fields blocking issue creation 




2017-04-03 11:10

developer   ~0056350

may be related to 0008957 ?



2017-04-03 11:21

developer   ~0056351

may be related to 0008957 ?

Maybe, but IIRC I did test it.
I had no time to have a deeper look, maybe it's caused by the late merge of the filter fixes from 2.2.3.



2017-04-03 14:13

developer   ~0056355

Previously date format was:


Now, the the format is:

filter_by_start_date:01-01-2015 00:00
filter_by_end_date:30-01-2015 00:00

New filter properties:
has been added to replace previous filter properties for respective year, month and day

  • The Build for query conditions is wrong
  • Stored filter values saved as old format are not converted, so it breaks backwards compatibility
  • seems like search.php for permaliks seems to have changed without fallback for old filters (haven't tested)

I'm sorry to not have looked to that PR, as i have been some time away...
For one side, it has changed filter structure, which we were trying to avoid at this point
And, if we are going to introduce changes in filter dates, we should do it properly:

  • providing a backwards compatibility for user stored filters and permalinks
  • optionally, increasing filter version number
  • implement a better date filter, as mentioned in 0022021 and 0022020, which has been set to wait to not change filter structure atm.

I see some options:
1) Modify the new implementation for Date chooser to use the old filter structure for dates
2) Implement a new date property consistent with the planned improvements.

As i see it, (2) should be implemented sooner or later, i'd rather not support an intermediate filter structure.



2017-04-03 17:12

developer   ~0056360

Will take a look shortly and update this issue.



2017-04-03 17:18

developer   ~0056361

The dates properties are strored as strings that are dependant on $g_normal_date_format
Changing this option, or having it configured per user, may breack the functionality

Eg, this is from the json record in filters table:
"filter_by_start_date":"01-01-2015 00:00",
"filter_by_end_date":"30-01-2015 00:00"



2017-04-03 17:35

developer   ~0056362

Will take a look shortly and update this issue.


My suggestion is:

  • revert to previous year / month / day filter properties. Use the new string format only to populate the widget, and to read submitted values
  • revert permalinks modifications
  • revert filter sql generation (since no change in filter structure is left)

Then, as the date string is short lived, only for the rendered form, the $g_normal_date_format issue is not a big problem. However a non localized format is preferable, what if a integer timetamp is used and converted as needed?

Let me know if i can help.



2017-04-05 13:03

developer   ~0056396

Last edited: 2017-04-05 13:04

View 2 revisions

@cproensa I cannot repro it on my local dev box. Can you share the following config values:

$g_short_date_format = 'Y-m-d';
$g_normal_date_format = 'Y-m-d H:i';
$g_datetime_picker_format = 'Y-MM-DD HH:mm';

I assume you did not change these values recently, right?

Btw, my test database is an older version of mantisbt database.



2017-04-05 14:54

developer   ~0056399

I guess you are trying to reproduce this:

The dates properties are strored as strings that are dependant on $g_normal_date_format
Changing this option, or having it configured per user, may breack the functionality

I use this setting:
$g_normal_date_format = 'd-m-Y H:i';

So with that setting, my filter is saved with these values:
"filter_by_start_date":"01-01-2015 00:00",
"filter_by_end_date":"30-01-2015 00:00"

After changing $g_normal_date_format, eg, for default value 'Y-m-d H:i', date fed to the calendar widget is wrongly parsed.



2017-04-05 15:54

developer   ~0056401

Last edited: 2017-04-05 15:55

View 2 revisions


The issue is much more simpler that it appears. See pull request for details.
@cproensa can you please test and verify that your existing filters work again?



2017-04-06 04:24

developer   ~0056406

PR 1079 does not address:

  • Breaks backwards compatibility with stored filters and permalinks
  • Changing $g_normal_date_format breaks filter functionality: string date in filter is stored based on user configuration. When building the query it's directly fed to strtotime(), which fails with unsupported formats like: $g_normal_date_format = 'd/m/Y H:i'
  • Changing $g_normal_date_format show dates in widget incorrectly when loading stored dates with a different format. For example: "30/01/2015 00:00" is converted to 2030-01-20 00:00 when configuration changes.

However, my main concern is that filter structure has changed, which is not required for the new widget implementation, and that is the main reason for the problems.



2017-04-16 19:30

developer   ~0056595

@cproensa, please update this issue following merge of PR



2017-04-16 19:39

developer   ~0056597

Fixed after reverting the original changes that caused the issues

Issue History

Date Modified Username Field Change
2017-04-03 08:36 atrol New Issue
2017-04-03 11:10 cproensa Note Added: 0056350
2017-04-03 11:21 atrol Note Added: 0056351
2017-04-03 14:13 cproensa Note Added: 0056355
2017-04-03 17:12 syncguru Note Added: 0056360
2017-04-03 17:18 cproensa Note Added: 0056361
2017-04-03 17:35 cproensa Note Added: 0056362
2017-04-04 06:44 cproensa Relationship added related to 0022663
2017-04-04 06:48 cproensa Status new => confirmed
2017-04-05 13:03 syncguru Note Added: 0056396
2017-04-05 13:04 syncguru Note Edited: 0056396 View Revisions
2017-04-05 14:54 cproensa Note Added: 0056399
2017-04-05 15:54 syncguru Note Added: 0056401
2017-04-05 15:55 syncguru Note Edited: 0056401 View Revisions
2017-04-06 04:24 cproensa Note Added: 0056406
2017-04-06 17:57 cproensa Relationship added related to 0008957
2017-04-16 19:30 dregad Note Added: 0056595
2017-04-16 19:39 cproensa Assigned To => cproensa
2017-04-16 19:39 cproensa Status confirmed => resolved
2017-04-16 19:39 cproensa Resolution open => fixed
2017-04-16 19:39 cproensa Fixed in Version => 2.3.1
2017-04-16 19:39 cproensa Note Added: 0056597
2017-04-16 19:47 dregad Status resolved => closed