View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0001809||OXID eShop (all versions)||1.03. Basket, checkout process||public||2010-05-01 21:02||2012-12-10 13:23|
|Product Version||4.3.1 revision 27257|
|Target Version||Fixed in Version||4.6.0_beta1|
|Summary||0001809: Faulty date and timestamp values within oxorderarticles entries|
|Description||1) Order processing: INSERTs of oxorderarticle use the copied values of the assigned oxarticle object.|
2) Order updating (e.g. within admin order_article class): Updating oxorderarticle requires to skip oxtimestamo field, which will be updated by database (on update CURRENT_TIMESTAMP).
Simply like it's done within oxarticle the following would fix it for oxorderarticle:
protected function _insert()
// set oxinsert
$iInsertTime = time();
$now = date('Y-m-d H:i:s', $iInsertTime);
$this->oxorderarticles__oxinsert = new oxField( $now );
$this->oxorderarticles__oxtimestamp = new oxField( $now );
protected function _skipSaveFields()
$this->_aSkipSaveFields = array();
$this->_aSkipSaveFields = 'oxtimestamp';
$this->_aSkipSaveFields = 'oxinsert';
protected function _update()
Reminder sent to: thomas_oppelt
sorry, but i did not fully understand the problem you described. at the moment, it works this way:
when order is done in frontend, all product information (including OXINSERT and OXTIMESTAMP fields) is coppied into oxorderarticles db table.
if this order is updated via admin interface (changed amount of ordered product), OXINSERT and OXTIMESTAMP fields are not changed and stay the same. if new product is added to order via admin interface, OXINSERT and OXTIMESTAMP fields are coppied from oxarticle table for that product.
Are OXINSERT and OXTIMESTAMP fields changed in your case during order update via admin?
1) In a way you are right, my analysis did not match what actually happens, what appears seem to be a date (re)formatting issue, try this to reproduce:
Ordering within GERMAN language, then you get a "d.m.Y" formatted date within insert statement of oxorderarticle, which has to fail (e.g. 23.10.2009 becomes 2023-10-20 .. some databases of german shops we checked for that are full with nonsense dates which lie ahead like this.)
2) oxorderarticle.OXTIMESTAMP has an "on update CURRENT_TIMESTAMP" attribute so of course it is intended to be updated by database itself, or not?
||added 'oxtimestamp' to _aSkipSaveFields array and fixed, that 'oxorderarticeles.oxinsert' is the same as 'oxarticeles.oxinsert'.|