I am currently working on a new feature on our B2B shop, that will allow some users to claim ownership of carts created by other users within the same company/organization.Example on use case: Person A creates a new cart, and saves it as a draft. Person B then takes ownership of that cart, in order to add more products and complete the order.
Our current implementation requires that the CustomerId on the cart matches the ID of the current user.
I have already made the logic, that succesfully updates the CustomerId along with some properties in the "Data" field. I have verified that everything looks corrent in the database after the cart is saved with the new CustomerId.That means that everything is working for Person B in the above example.
The cart is updated using this EPiServer method.
My problem is that the cart is still returned when we load carts belonging to Person A, for a periode of time after the update.I have come to the conclusion, that this is due to the cache inside the OrderRepository. Carts are loaded using this EpiServer method.
For a period of time, the updated cart is still returned when carts are loaded for Person A.In that result, the cart still contains the CustomerId of Person A.
Can any of you think of a way to solve this problem?Is it somehow possible to refresh the cache of Person A, when Person B takes ownership of one of his/her carts?
As you found out, the orders are cached by the Customer ID until it expires or it is invalidated.
You can do either of these two options:
Option 1 corresponds to taking ownership of the cart, as you put it.
Option 2 is more like copying the cart and deleting the original.
But the end result would be the same.
Thank you for the answerDo you know the format of that cache key, or where to find it?
I actually had something like Option 2 in mind as an alternative solution.
Generally you can use the Episerver DeveloperTools add-on to inspect local cache items and then derive patterns of cache keys.
I found this example for you (replace the parts with your own values):
Be aware that this is a derived cache key format. Although I doubt it will suddenly change, there is no guarantee that it won't.
Changing CustomerId is quite unusual thing to do, but it's argubly a bug... I will see if we can do anything about it.
Stefan, you are my hero of the week!
That cache invalidation was the final piece to my puzzle. Now everything works as intended.