|
|
| Reporter | sauron | Assigned To | infrastation | |
|---|
| Priority | normal | Severity | major | Reproducibility | always |
|---|
| Status | closed | Resolution | fixed | |
|---|
| Product Version | 0.20.3 | |
|---|
| Target Version | 0.20.4 | Fixed in Version | 0.20.4 | |
|---|
|
|
| Summary | 719: Major regression in date handling |
|---|
| Description | After a recent upgrade from Racktables 0.19.2 to 0.20.3, almost all dates entered have disappeared from the interface.
|
|---|
| Steps To Reproduce | For an example object in my DB:-
> select * from AttributeValue where object_id = 320;
+-----------+------------+---------+--------------+------------+-------------+
| object_id | object_tid | attr_id | string_value | uint_value | float_value |
+-----------+------------+---------+--------------+------------+-------------+
| 320 | 4 | 1 | 0832QAN125 | NULL | NULL |
| 320 | 4 | 2 | NULL | 50015 | NULL |
| 320 | 4 | 4 | NULL | 1395 | NULL |
| 320 | 4 | 21 | 21/04/2013 | NULL | NULL |
| 320 | 4 | 22 | 10/09/2009 | 1255046400 | NULL |
+-----------+------------+---------+--------------+------------+-------------+
in 0.19.2, attribute ids 21 and 22 (support contract expiration and HW warranty expiration) were strings, but with the new version, they have been changed to "date" data types. These fields are no longer visible, and this is affecting all objects in the database, thus all my support/warranty information is no longer visible across the board. |
|---|
| Additional Information | Additionally, the date handling for the new field types doesn't appear to work properly - or not as expected, anyway. The config value DATETIME_FORMAT appears to be used for displaying dates, but not for entering them, and the entry is a simple wrapper around strtotime(), which seems unable to handle "/" separators, among other things. Using the PHP parse_date() function would probably be more robust, but for non US users, there is still an issue with date output being controlled by the DATETIME_FORMAT, but input localisation seems to be governed by the php.ini date.timezone setting, which has the potential for a lot of confusion. |
|---|
| Tags | No tags attached. |
|---|
|
|
