View Issue Details

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

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.

Relationships

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

Activities

cproensa

cproensa

2017-04-03 11:10

developer   ~0056350

may be related to 0008957 ?

atrol

atrol

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.

cproensa

cproensa

2017-04-03 14:13

developer   ~0056355

Previously date format was:

filter_by_date:on
start_day:1
start_month:1
start_year:2015
end_day:30
end_month:1
end_year:2015

Now, the the format is:

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

New filter properties:
FILTER_PROPERTY_START_DATE_SUBMITTED
FILTER_PROPERTY_LAST_UPDATED_START_DATE
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.

syncguru

syncguru

2017-04-03 17:12

developer   ~0056360

Will take a look shortly and update this issue.

cproensa

cproensa

2017-04-03 17:18

developer   ~0056361

Additionally:
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"

cproensa

cproensa

2017-04-03 17:35

developer   ~0056362

Will take a look shortly and update this issue.

Thanks

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.

syncguru

syncguru

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.

cproensa

cproensa

2017-04-05 14:54

developer   ~0056399

@syncguru
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.

syncguru

syncguru

2017-04-05 15:54

developer   ~0056401

Last edited: 2017-04-05 15:55

View 2 revisions

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

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?

cproensa

cproensa

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.

dregad

dregad

2017-04-16 19:30

developer   ~0056595

@cproensa, please update this issue following merge of PR https://github.com/mantisbt/mantisbt/pull/1093

cproensa

cproensa

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