View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0000704 | OXID eShop (all versions) | 1.01. Products (product, categories, manufacturer, promotions etc.) | public | 2009-03-16 10:06 | 2012-12-07 14:29 |
Reporter | Nico_Klein | Assigned To | |||
Priority | normal | Severity | major | Reproducibility | random |
Status | resolved | Resolution | fixed | ||
Fixed in Version | 4.1.0 revision 17976 | ||||
Summary | 0000704: OXINSERT is zero | ||||
Description | After the creating of a new article in the columns OXINSERT and OXTIMESTAMP stand the correct information. Thats Okay. But, if you load up some pictures of the product in the column OXINSERT stands 0000-00-00. The column OXTIMESTAMP has the correct content (the time of updating). In my opinion, the content of OXINSERT should remain unchanged. | ||||
Tags | Products | ||||
Theme | |||||
Browser | All | ||||
PHP Version | 5.2.6 | ||||
Database Version | 5.0.33 | ||||
|
I can confirm a misbehaviour of the picture upload procedure. But in my case the OXINSERT column is set to dates in the far future (e.g. 2028). |
|
Reminder sent to: Nico_Klein Hi, I cannot reproduce this case localy. Did you tested with demodata? or have some shop installed? Is there some additional modules installed, which may affect the data in oxarticle table? Best regards, |
|
Reproducibility changed to "random". @developers: please check from the source code side if there is possibility for such issue: - during picture upload the value in OXINSERT columns is reset to 0 or to some future date (i.e. 2028) |
|
Unable to reproduce - maybe reporter can give more information, which shop version, uploading one or few images and so on... |
|
Message from sannc: I reproduced the behaviour: 1. Added new article "TEST" with admin 2. SQL statement SELECT OXINSERT, OXTIMESTAMP FROM `oxarticles` WHERE OXARTNUM = 'TEST' shows OXINSERT OXTIMESTAMP 2009-03-20 2009-03-20 16:31:40 3. Added picture (picture 1) 4. Same SQL statement shows OXINSERT OXTIMESTAMP 2020-03-20 2009-03-20 16:37:08 Please not the wrong date in OXINSERT. MySQL Version: mysql Ver 14.12 Distrib 5.0.70, for pc-linux-gnu (x86_64) using readline 5.2 |
|
Hi, Very strange. As according to your description, I made the same behaviour and still for me it shows: - before picture insert: OXINSERT OXTIMESTAMP 2009-03-24 2009-03-24 10:23:00 - after: 2009-03-24 2009-03-24 10:25:12 both dates are correct. Are you testing on fresh shop installation? With shop's demo data? Which exact shop version it is? Do you have some modules installed in the shop? Best regards, |
|
Reopened the case as it's possible that it can be reproduced. Waiting for details from reporter. |
|
Hi! Just tested on a blank installation (V.4.0.1.0) with just the PayPal Portlet installed. Same misbehaviour. The false date is 2024-03-20 ... the date I added the article was 2009-03-24 10:49:10. Today is March 24th ... the false date is in 2024 ... seems as if there is a misinterpretation of the date written into the database. Maybe a locale issue? Best regards Carsten Sann |
|
I have tested this with an CE 4.0.1.0 rev. 15990 and the original demo data. The modul, that is installed, is the invoicepdf/myorder modul. |
|
Ah... found :) the bug occurs only if during login to admin area the selected language is Deutsch. So case is reproduced and will be fixed. @Developers: also please check why behaviour depends on the selected language. |
|
It's obvious why the language has effect on that: In class oxarticle the load method does this: $this->oxarticles__oxinsert = new oxField(oxUtilsDate::getInstance()->formatDBDate( $this->oxarticles__oxinsert->value)); $this->oxarticles__oxtimestamp = new oxField(oxUtilsDate::getInstance()->formatDBDate( $this->oxarticles__oxtimestamp->value)); So the date is formated - but only in german language, cause in english it's kept as it is stored in the DB. In method save() of oxarticle there is a re-format function missing. Cause the object in german language now has something like this: [oxarticles__oxinsert] => oxField Object ( [rawValue] => 27.03.2009 ) [oxarticles__oxtimestamp] => oxField Object ( [rawValue] => 26.03.2009 11:56:26 ) And if you now store this - without reformating - you get the known effect. |