View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0007136 | OXID eShop (all versions) | 4.12. Subshop handling | public | 2020-05-11 16:48 | 2024-08-07 11:09 |
| Reporter | matths | Assigned To | |||
| Priority | immediate | Severity | crash | Reproducibility | always |
| Status | resolved | Resolution | fixed | ||
| Product Version | 6.1.5 | ||||
| Fixed in Version | 6.2.2 | ||||
| Summary | 0007136: Shop deletes savedbasket entries from other (all) subshops | ||||
| Description | In an OXID Enterprise Edition (EE) Shop Setup with multiple subshops, if in the OXID Admin the shop configuration for basket reservation is enabled (blPsBasketReservationEnabled) within one subshop, the next time a user interacts with his basket in this subshop, alls saved baskets less recent than configured for this subshop (iPsBasketReservationTimeout) are removed from the database, no matter their relation to this subshop. So userbasets of type savedbasket from users of a different subshop are deleted because of enabled basket reservation in another subshop. https://github.com/OXID-eSales/oxideshop_ce/blob/v6.3.6/source/Application/Model/BasketReservation.php#L300 The settings for basket reservation (blPsBasketReservationEnabled and iPsBasketReservationTimeout) are stored in relation to a shopid in the config table and configured in OXID Admin with a subshop selected. So the expectation of the shop owner is, that no other subshop is harmed by that configuration. Also when a userbasket doesn't have a shopid field, it relates to a user which might very well have a shopid. | ||||
| Steps To Reproduce | * setup OXID EE with at least two subshops * do not share users between subshops * put articles in your basket in shop 2 but do not order * enable basket reservation and a short period timeout for shop 1 * put articles in your basket in shop 1 * wait the short period of time * interact with basket in shop 1 * see saved basket of shop 2 user gone | ||||
| Additional Information | shop/vendor/oxid-esales/oxideshop-ce/source/Application/Component/BasketComponent.php::init() triggers shop/vendor/oxid-esales/oxideshop-ce/source/Application/Model/BasketReservation.php::discardUnusedReservations which deletes all the savedbasket userbasket entries $database->execute("delete from oxuserbaskets where oxtitle = 'savedbasket' and oxupdate <= $iStartTime"); There should be a EE implementation for discardUnusedReservations. We might provide a basic example as Pull Request if we get access to the Github Repo again. | ||||
| Tags | Basket, EE, Reservation, Subshops | ||||
| Attached Files | |||||
| Theme | Not defined | ||||
| Browser | Not defined | ||||
| PHP Version | Not defined | ||||
| Database Version | Not defined | ||||
|
|
Could not been reproduced in OXID 6.2.1. Please make an update and try again. -MF |
|
|
Come on. Don't take my "Steps To Reproduce" as 1:1 but think about what I've written in the description and what leads to the deletion of savedbasket Userbaskets! The DELETE statement is still in the most recent CE code. I can't imagine there's an EE fix for that in between 6.1.5 and 6.2.1. I might be wrong here, but I doubt. We have lost userbaskets and it is not a fun error reporting. Have you tried with 6.1.5? |
|
|
We have tested it with Enterprise Edition 6.1.6 and can't reproduce it there, too. Please provide 1:1 steps to reproduce. |
|
|
I currently can't afford the time to setup a clean, standard 6.1.6 EE with at least two subshops, but I am reducing side effects from our customizings to ensure the problem is in the oxid standard as well. And I'm really sure, it is. As mentioned before, it's all about the database DELETE statement in https://github.com/OXID-eSales/oxideshop_ce/blob/v6.3.6/source/Application/Model/BasketReservation.php#L300 So I expected you to find out, when this line is run through by yourself as you should know best. So I can reproduce the savedbasket loss by foloowing these steps in our shop setup and with customizings (modules) reduced as much as possible. You need at least two subshops. configuration of subshop 1 blPsBasketReservationEnabled 1 iPsBasketReservationTimeout 60 configuration of subshop 2 blPsBasketReservationEnabled 0 to make it more obvious: truncate the oxuserbaskets table 1. As signed-in user A put an article into your basket in subshop 2. In oxuserbaskets, there's an additional row "savedbasket". oxuserbaskets table has one row. wait for as long you like 2. As signed-in user B put an article into your basket in subshop 1. In oxuserbaskets, there's an additional row "reservations". oxuserbaskets table has two rows, now. within the next 60 seconds... 3. As signed-in user C put an article into your basket in subshop 1. In oxuserbaskets, there's an additional row "reservations". oxuserbaskets table has three rows, now. wait at least 60 seconds... 4. As User B, still logged in, call the start page of your shop, which consists of the mini basket widget, which initializes the BasketComponent. Now, the oxuserbaskets table is empty again and has lost its rows, also the "savedbasket" of user A from subshop 2 is gone. after some more time... 5. As user A I delete my session cookie and login to subshop 2 again. I would expect my saved basket to be available again, but my basket is empty. But again, I think my initial description has given you all what's needed: The delete statement, once it is run through, is to general for a multi shop enterprise edition with basket reservation turned on in only one subshop: delete from oxuserbaskets where oxtitle = 'savedbasket' and oxupdate <= $iStartTime This deletes saved baskets from other subshops, which is not funny at all. Br, Matthias |
|
|
It seems your shop does not behave like a standard shop installation. In step 1 I also have one row with savedbaskets in oxuserbaskets table. But in step 2 have three rows. Two savedbaskets and one reservations. If I follow your steps I can't reproduce the empty basket. To verify bugs it is recommended to install a new shop with demo data on a test system to try to reproduce the behavior there as well. |
|
|
I am upset, I point you to the obvious DELETE database query in question, and you don't even try hard enough to let the shop logic run through that line of code and see its fatal outcome. It costs my time and my customers money to do this even more precisely: * I installed a clean OXID 6.1 EE following the manual from https://github.com/OXID-eSales/oxvm_eshop/tree/b-6.1 * I created another mall: "subshop 2" * for subshop 1 I disable savedbaskets in the performance settings, but enabled reservations or basket expiration of 5 minutes * for subshop 2 savedbaskets are enabled by default and reservations disabled by default * I logged into subshop 2 and put an article in the basket, which leads to a savedbasket row in oxuserbaskets * Now I put different kites and stuff in my basket with different users or as guest in subshop 1 * After more than 5 minutes later I just opened the subshop 1 start page and all entries to oxuserbaskets are gone I made a screenshot story for you to see it yourself, see attached zip archive. |
|
|
Reproducible (also in 6.2.1) with the additional given information of the performance setting "Don't save Shopping Carts of registered Users" in subshop 1. |
