Add behat test scenarios for wholesale_price change when assigning supplier

[zuk3975]

Questions	Answers
Branch?	develop
Description?	Adds missing behat tests scenario to support some logic when supplier is assigned to product. When default supplier is assigned to standard product, then product->wholesale_price should be copied from that supplier price. read more #20544 (comment) and #20198 (comment)
Type?	refacto
Category?	BO
BC breaks?	no
Deprecations?	no
Fixed ticket?	related to #19683
How to test?	Travis ✔️

---

This change is 

[zuk3975]

The test is constantly failing due duplicate key in ps_layered_price_index. It might be a good chance to tackle down that problem, as it might not only be a caching issue, but actual bug with combinations and faceted search module 🤔

[zuk3975]

ps_facetedsearch.php indexProductPrices() the final result of values to be inserted are (in ps_facetedsearch.php L551)

[
    "(23,2,1, ,21)"
    "(23,7,1, ,21)"
]

Im not actually sure its bug in module or it is test fault, maybe some undesired stuff is happening because there is 7 currencies created (5 of which are USD) during tests 😓

[matks]

@zuk3975 Did you find the answer about ps_facetedsearch?

[zuk3975]

| @zuk3975 Did you find the answer about ps_facetedsearch?

yep It was caching issue related to combination, this seemed to help 1e94d99
this is how prices are related to supplier:
When supplier is updated, product->id_supplier (along with supplier_reference and wholesale_price) must be updated too, so then we invoke Product->update() , which triggers hook actionProductSave, which is used by facetedsearch to invoke Product::priceCalculation.
priceCalculation used to return null because cache was not empty (but not filled by needed attributes too).

based on screenshot the $_pricesLevel2[$cache_id_2] was set, but [$id_product_attribute] wasn't.

[zuk3975]

clearing cache manually, doesn't seem like a good solution yet, its still under investigation 🕵️ , so don't rush to merge 😅

[jolelievre]

@zuk3975 after a few search on my side I did notice the same problems you mentioned, the root problem indeed came from the Product::priceCalculation method and especially its cache which:

• is filled based on productId (cache key)
• stored all the attributes prices
• returns null (not even zero) when it doesn't find the price for request attribute

The problem here is that the cache was filled on product creation, then combinations were created but the cache didn't know them so it didn't know their prices and returned null..

I added two fixes for this:

• most important now Product::priceCalculation checks if the specified attribute cache is set, if not it rebuilds it for all attributes, this should prevent a lot of problems
• when combinations are created by behat tests, the context calls Product::resetStaticCache() for extra safety to avoid encountering similar problems related to combination cache in the future

[matks]

Thank you @zuk3975 and @jolelievre