View Issue Details
ID | Project | Category | View Status | Date Submitted | Last Update |
---|---|---|---|---|---|
0006223 | OXID ERP Interface | OXID ERP Interface - sub | public | 2015-08-31 16:20 | 2019-12-17 08:59 |
Reporter | andreas_ziethen | Assigned To | |||
Priority | high | Severity | minor | Reproducibility | always |
Status | resolved | Resolution | fixed | ||
Product Version | 2.14.0 | ||||
Fixed in Version | 2.14.2 | ||||
Summary | 0006223: shopid switches to 1 if tmp file cache is cleared during import | ||||
Description | Theres (probably) a bug in oxerpbase which causes a change of the shopid during long lasting imports. Shop-ID is set to "1" if the tmp file cache has been cleared. The reason can be found in oxerpbase:: loadSessionData() up from line 337: if (oxNew('OXERPCompatibility')->isShopEE()) { $oUtils = $this->getUtils(); $aSessionCache = $oUtils->fromFileCache( "erp_c_fieldnames_" . $sSessionID ); $iLang = $aSessionCache['lang']; $myConfig->setShopId( $aSessionCache['actshop'] ); } So if the file is not found, shopid will be empty here, which causes a switch to shopid "1" later on. A missing tmp file can be caused by some cache resetting operations during long lasting imports (several hours). We discovered the problem when we had a huge import of data from ERP system to the shop and we noticed that quite a lot of subshop prices ended up in oxarticles table instead of oxfield2shop table. | ||||
Steps To Reproduce | Start ERP import for subshops and during the run just empty the tmp folder. You will notice that from now on all the data go to shop "1" instead of the right subshops. | ||||
Additional Information | One possible solution (of one our developers) can be found in the attached file. | ||||
Tags | Solution Provided | ||||
Attached Files | oxERPBase__loadSessionData.php (2,395 bytes)
<?php abstract class oxERPBase { /** * oxERPBase::loadSessionData() * load session - should be called on init * * @param string $sSessionID session id * @param bool $blAdminMode admin mode ( default is on, due to #4617 once it must be off ) * @return null */ public function loadSessionData($sSessionID, $blAdminMode = true) { if (!$sSessionID) { throw new Exception("ERROR: Session ID not valid!"); } $_COOKIE = array('admin_sid' => $sSessionID); // change session if needed if ($sSessionID != session_id()) { if (session_id()) { session_write_close(); } session_id($sSessionID); session_start(); } $myConfig = oxRegistry::getConfig(); $myConfig->setConfigParam('blAdmin', 1); $myConfig->setAdminMode($blAdminMode); $iShopId = null; $iLang = null; if (oxNew('OXERPCompatibility')->isShopEE()) { $oUtils = oxRegistry::getUtils(); $aSessionCache = $oUtils->fromFileCache("erp_c_fieldnames_" . $sSessionID); if (is_array($aSessionCache)) { $iLang = isset($aSessionCache['lang']) ? $aSessionCache['lang'] : null; $iShopId = isset($aSessionCache['actshop']) ? $aSessionCache['actshop'] : null; } } $mySession = oxRegistry::getSession(); if ($iLang === null) { $iLang = $mySession->getVariable("lang"); } if ($iShopId === null) { if (oxNew('OXERPCompatibility')->isShopEE()) { $iShopId = $mySession->getVariable("actshop"); $oUtils = oxRegistry::getUtils(); $oUtils->toFileCache( "erp_c_fieldnames_" . $sSessionID, array( "actshop" => $iShopId, "lang" => $iLang ) ); $oUtils->commitFileCache(); } } $myConfig->setShopId($iShopId); $sAuth = $mySession->getVariable('auth'); if (!isset($sAuth) || !$sAuth) { throw new Exception("ERROR: Session ID not valid!"); } $this->_iLanguage = $iLang; $this->_sUserID = $sAuth; $this->_blInit = true; } } | ||||
|
Problem can occur if: 1. You are using EE 2. You have subshops 3. You add something to subshop 4. You use ERP interface 5. clean tmp after ERP login and before something is added (Normally tmp folder is not cleared while shop is running) Reduced severity because this combination is a rare case. |
|
Actually, I'm not sure if it's a "rare case" cause we did not find out yet WHY tmp files are deleted. As the import runs up from 4:00 am and the shop is not live yet, we can be pretty sure that nobody deleted tmp files willingly. There must be some shop operation which cause the deletion. So this actually may be another bug? |
|
There is a pattern which prevents the shop from deleting the files in tmp which are needed for ERP. See here: https://github.com/OXID-eSales/oxideshop_ce/blob/b-dev-ce/source/core/oxutils.php#L49 That must be a function of a module or maybe a server cron job which deletes the tmp files. |
|
We're having the exact same issue. We noticed, that sometimes the importer wrote to shop 1 instead of the given shop-id from the session and analyzed it further. We found out, that the import broke every time after we deployed a new release. We clear the cache during our deployment process and kind of reset the shop-id in the erp session by that. I don't think, that this is a rare case, since most projects use automated deployments these days where you clear the cache with every deployment. |
|
The mentioned pull request https://github.com/OXID-eSales/erp/pull/8 is present in v3.1.0 and v2.14.2 so the issue is fixed |