{"action":"opened","issue":{"url":"https://api.github.com/repos/osTicket/osTicket/issues/3225","repository_url":"https://api.github.com/repos/osTicket/osTicket","labels_url":"https://api.github.com/repos/osTicket/osTicket/issues/3225/labels{/name}","comments_url":"https://api.github.com/repos/osTicket/osTicket/issues/3225/comments","events_url":"https://api.github.com/repos/osTicket/osTicket/issues/3225/events","html_url":"https://github.com/osTicket/osTicket/issues/3225","id":161852086,"number":3225,"title":"1.10 RC3 datetime form data broken","user":{"login":"GoodbyeWorld","id":2569504,"avatar_url":"https://avatars.githubusercontent.com/u/2569504?v=3","gravatar_id":"","url":"https://api.github.com/users/GoodbyeWorld","html_url":"https://github.com/GoodbyeWorld","followers_url":"https://api.github.com/users/GoodbyeWorld/followers","following_url":"https://api.github.com/users/GoodbyeWorld/following{/other_user}","gists_url":"https://api.github.com/users/GoodbyeWorld/gists{/gist_id}","starred_url":"https://api.github.com/users/GoodbyeWorld/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/GoodbyeWorld/subscriptions","organizations_url":"https://api.github.com/users/GoodbyeWorld/orgs","repos_url":"https://api.github.com/users/GoodbyeWorld/repos","events_url":"https://api.github.com/users/GoodbyeWorld/events{/privacy}","received_events_url":"https://api.github.com/users/GoodbyeWorld/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2016-06-23T06:51:50Z","updated_at":"2016-06-23T06:51:50Z","closed_at":null,"body":"Upgraded from 1.10 RC2 to 1.10 RC3, release afd63e1198c5c7d7f6dd6c9057f176d9b007242f\r\n\r\nIt appears that there's been a change around how datetime form values are stored, and as a result, after upgrading all the datetime values in my tickets are no longer being displayed.  \r\n\r\nHere's how my form fields are defined in the ost_form_field table:\r\n\r\n```\r\nMariaDB [support]> select * from ost_form_field where form_id = 8 \\G\r\n*************************** 1. row ***************************\r\n           id: 40\r\n      form_id: 8\r\n        flags: 30465\r\n         type: datetime\r\n        label: Baby Due-Date\r\n         name: babyDue\r\nconfiguration: {\"time\":false,\"gmt\":false,\"min\":\"\",\"max\":\"\",\"future\":true}\r\n         sort: 1\r\n         hint: Please tell us your approximate due-date. We need to know the due-date to prepare the gift. We try to provide clothes that are appropriate for each season, and the due-date helps us to understand what sizes your baby will need when.\r\n      created: 2015-12-26 16:05:31\r\n      updated: 2016-06-23 06:32:40\r\n*************************** 2. row ***************************\r\n           id: 41\r\n      form_id: 8\r\n        flags: 30465\r\n         type: choices\r\n        label: Sex\r\n         name: babyGender\r\nconfiguration: {\"choices\":\"Boy\\r\\nGirl\\r\\nMultiple Babies (Twins etc.)\\r\\nIt will be a surprise\\r\\nI hope to find out before delivery date\",\"default\":\"\",\"prompt\":\"\",\"multiselect\":false}\r\n         sort: 2\r\n         hint: We need to know the sex of your baby before we can begin preparing your gift. If you're unsure now, you can always update this later once you know.\r\n      created: 2015-12-26 16:05:31\r\n      updated: 2016-01-01 16:15:28\r\n2 rows in set (0.00 sec)\r\n\r\n```\r\n\r\nNotice that id 40 is a datetime type field.\r\n\r\nNow look at how the data was stored, and how it's now being stored (output truncated to save space here):\r\n\r\n```\r\n*************************** 219. row ***************************\r\nentry_id: 2507\r\nfield_id: 40\r\n   value: 1470528000\r\nvalue_id: NULL\r\n*************************** 220. row ***************************\r\nentry_id: 2514\r\nfield_id: 40\r\n   value: 1462147200\r\nvalue_id: NULL\r\n*************************** 221. row ***************************\r\nentry_id: 2521\r\nfield_id: 40\r\n   value: 2016-10-07 00:00:00\r\nvalue_id: NULL\r\n*************************** 222. row ***************************\r\nentry_id: 2528\r\nfield_id: 40\r\n   value: 2016-06-23 00:00:00\r\nvalue_id: NULL\r\n*************************** 223. row ***************************\r\nentry_id: 2535\r\nfield_id: 40\r\n   value: 2016-07-28 00:00:00\r\nvalue_id: NULL\r\n*************************** 224. row ***************************\r\nentry_id: 2542\r\nfield_id: 40\r\n   value: 2016-06-22 00:00:00\r\nvalue_id: NULL\r\n224 rows in set (0.00 sec)\r\n```\r\n\r\nNotice how the values change from Unix epoch time stamps to date-time strings at row 221 - this is the first ticket received since upgrading to RC3.  Rows prior to 221 were with RC2.\r\n\r\nAs a result of this change, dates are no longer visible to agents when working with tickets opened back on RC2.  When viewing the ticket, the entire field (Baby Due-Date) is missing entirely.  If they choose to edit, the value is \"0\", and they can set a new datetime value by using the popup calendar widget.\r\n\r\nI can manually correct this by editing the data (converting from epoch to date time string), but I thought I should report this since I'm sure others will be affected.  \r\n\r\nCan this be worked around in the code, so it detects and accommodates either the epoch or date time string values correctly?\r\n\r\nThanks"}}
{"actor":{"display_login":"GoodbyeWorld"}}