View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0022653||mantisbt||filters||public||2017-04-03 08:36||2017-04-16 19:47|
|Target Version||2.3.1||Fixed in Version||2.3.1|
|Summary||0022653: Regression: Filter by date broken|
|Tags||No tags attached.|
may be related to 0008957 ?
Maybe, but IIRC I did test it.
Previously date format was:
Now, the the format is:
New filter properties:
I'm sorry to not have looked to that PR, as i have been some time away...
I see some options:
As i see it, (2) should be implemented sooner or later, i'd rather not support an intermediate filter structure.
Will take a look shortly and update this issue.
Eg, this is from the json record in filters table:
My suggestion is:
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.
@cproensa I cannot repro it on my local dev box. Can you share the following config values:
$g_short_date_format = 'Y-m-d';
I assume you did not change these values recently, right?
Btw, my test database is an older version of mantisbt database.
I use this setting:
So with that setting, my filter is saved with these values:
After changing $g_normal_date_format, eg, for default value 'Y-m-d H:i', date fed to the calendar widget is wrongly parsed.
The issue is much more simpler that it appears. See pull request for details.
PR 1079 does not address:
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.
Fixed after reverting the original changes that caused the issues
|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|