You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The product variants have prices set with the region rule, and a price for each currency. These prices are "default" prices, which we create in the admin when creating a standard product. It's looks like:
Then create a valid price list (any type of price list) for the same product variant. Set the price in the price list higher than the “default” prices for the product (these “default” prices are described above).
Finally, try to get prices for this product variant using *variants.calculated_price and the official manual or Store API GetProduct - you will always get the price from the price list, despite the fact that the "default" price is lower and the price request contains region_id, currency_code and also the user is authorized. It's a bug.
Experimentally it was found out that if there is at least one valid price list - calculated_price context will not take into account any “default” prices at all. Despite the fact that “default” prices are lower than prices from price lists and “default” prices are also valid for selection, because the query contains region_id and currency_code for these prices.
(Actually calculated_price does not work with “default” prices at all if there is at least one valid price list. But if you specify prices lower than "default" prices in the price list, then everything looks correct, because the lowest price will be returned. Just thought I'd mention it, since it's also part of the bug, although the result is returned correctly.)
Expected behavior
It is expected that calculated_price will return the minimum of available and valid prices.
Actual behavior
calculated_price returns the minimum price, but only from the price lists (if there are several valid price lists - calculated_price will choose the minimum price from the price lists without taking into account the “default” prices).
Package.json file
Node.js version
v20.15.0
Database and its version
PostgreSQL 16.4
Operating system name and version
WIndows 11
Browser name
No response
What happended?
The product variants have prices set with the region rule, and a price for each currency. These prices are "default" prices, which we create in the admin when creating a standard product. It's looks like:
Then create a valid price list (any type of price list) for the same product variant. Set the price in the price list higher than the “default” prices for the product (these “default” prices are described above).
Finally, try to get prices for this product variant using *variants.calculated_price and the official manual or Store API GetProduct - you will always get the price from the price list, despite the fact that the "default" price is lower and the price request contains region_id, currency_code and also the user is authorized. It's a bug.
Experimentally it was found out that if there is at least one valid price list - calculated_price context will not take into account any “default” prices at all. Despite the fact that “default” prices are lower than prices from price lists and “default” prices are also valid for selection, because the query contains region_id and currency_code for these prices.
(Actually calculated_price does not work with “default” prices at all if there is at least one valid price list. But if you specify prices lower than "default" prices in the price list, then everything looks correct, because the lowest price will be returned. Just thought I'd mention it, since it's also part of the bug, although the result is returned correctly.)
Expected behavior
It is expected that calculated_price will return the minimum of available and valid prices.
Actual behavior
calculated_price returns the minimum price, but only from the price lists (if there are several valid price lists - calculated_price will choose the minimum price from the price lists without taking into account the “default” prices).
Link to reproduction repo
https://github.com/medusajs/medusa/
The text was updated successfully, but these errors were encountered: