[19.0][MIG] product_variant_sale_price: Migration to 19.0

[NICO-SOLUTIONS]

standard migration

[NICO-SOLUTIONS]

@eikido18
You can test it via Runboat (see the link in the Checks section) – it’ll spin up a test instance automatically.
If you’ve set up the OCA CLI, you can approve the PR right here on GitHub after confirming it works.

[eikido18]

If a product already has extra price (the old legacy way), and the product variant sale price is installed afterwards, those extra prices are still transferred in the website.

See here->
Before module installation (as is native odoo way).

After module installation (i can now set induvial variant prices, which i’ve done below):

Website shows the additional extra prices:

I don't think it's supposed to be this way?

[eikido18]

If i have products with extra price in my database, and i install the product variant sale price module, i get this error message (see details below).

To get it working, i need to “upgrade” the module.

Both reported issues tested on local installation and odoo.sh using Version 19. Same issue.

Odoo Server Error
RPC_ERROR
Odoo Server Error
Occured on masked:8069 on 2025-11-05 09:25:23 GMT
Traceback (most recent call last):
File "/opt/odoo19/odoo/http.py", line 2266, in _serve_db
return service_model.retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/odoo/service/model.py", line 184, in retrying
result = func()
^^^^^^
File "/opt/odoo19/odoo/http.py", line 2313, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/odoo/http.py", line 2528, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/odoo/addons/base/models/ir_http.py", line 357, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/odoo/http.py", line 788, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/addons/website_sale_stock_wishlist/controllers/variant.py", line 13, in get_combination_info_website
return super().get_combination_info_website(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/odoo/http.py", line 788, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/addons/website_sale_stock/controllers/variant.py", line 13, in get_combination_info_website
return super().get_combination_info_website(*args, **kwargs)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/odoo/http.py", line 788, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/opt/odoo19/addons/website_sale/controllers/variant.py", line 25, in get_combination_info_website
combination_info = product_template._get_combination_info(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
TypeError: ProductTemplate._get_combination_info() got an unexpected keyword argument 'uom_id'

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://masked:8069/web/assets/1/f61db8a/web.assets_frontend_lazy.min.js:4555:165)
at XMLHttpRequest. (http://masked:8069/web/assets/1/f61db8a/web.assets_frontend_lazy.min.js:4561:13)

[NICO-SOLUTIONS]

If a product already has extra price (the old legacy way), and the product variant sale price is installed afterwards, those extra prices are still transferred in the website.

See here-> Before module installation (as is native odoo way).

After module installation (i can now set induvial variant prices, which i’ve done below):
Website shows the additional extra prices:
I don't think it's supposed to be this way?

@eikido18
no it should not be that way... the extra price shoud be always zero on my opinion.
There was a change in the last FIX-commit.... i need to get into that a bit more. I´ll check it when i have some more free time.

[NICO-SOLUTIONS]

If i have products with extra price in my database, and i install the product variant sale price module, i get this error message (see details below).

To get it working, i need to “upgrade” the module.

Both reported issues tested on local installation and odoo.sh using Version 19. Same issue.

Odoo Server Error RPC_ERROR Odoo Server Error Occured on masked:8069 on 2025-11-05 09:25:23 GMT Traceback (most recent call last): File "/opt/odoo19/odoo/http.py", line 2266, in _serve_db return service_model.retrying(serve_func, env=self.env) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/odoo/service/model.py", line 184, in retrying result = func() ^^^^^^ File "/opt/odoo19/odoo/http.py", line 2313, in _serve_ir_http response = self.dispatcher.dispatch(rule.endpoint, args) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/odoo/http.py", line 2528, in dispatch result = self.request.registry['ir.http']._dispatch(endpoint) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/odoo/addons/base/models/ir_http.py", line 357, in _dispatch result = endpoint(**request.params) ^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/odoo/http.py", line 788, in route_wrapper result = endpoint(self, *args, **params_ok) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/addons/website_sale_stock_wishlist/controllers/variant.py", line 13, in get_combination_info_website return super().get_combination_info_website(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/odoo/http.py", line 788, in route_wrapper result = endpoint(self, *args, **params_ok) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/addons/website_sale_stock/controllers/variant.py", line 13, in get_combination_info_website return super().get_combination_info_website(*args, **kwargs) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/odoo/http.py", line 788, in route_wrapper result = endpoint(self, *args, **params_ok) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ File "/opt/odoo19/addons/website_sale/controllers/variant.py", line 25, in get_combination_info_website combination_info = product_template._get_combination_info( ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ TypeError: ProductTemplate._get_combination_info() got an unexpected keyword argument 'uom_id'

The above server error caused the following client error: RPC_ERROR: Odoo Server Error RPC_ERROR at makeErrorFromResponse (http://masked:8069/web/assets/1/f61db8a/web.assets_frontend_lazy.min.js:4555:165) at XMLHttpRequest. (http://masked:8069/web/assets/1/f61db8a/web.assets_frontend_lazy.min.js:4561:13)

@eikido18
i think this this should be fixed now with the last force push here.
My bad.
There was a small change on the parameters in _get_combination_info. Seems like i simply overlooked it.
Time is pretty rare right now. but i´ll attack this asap.

[NICO-SOLUTIONS]

@eikido18
Currently, in product_variant_sale_price we are NOT setting all product_template_attribute_value.price_extra to 0.

The intention is to ensure the shop does not display old extra prices and that only fix_price is used for variants.

@victoralmau
Do you think this could cause any compatibility issues with other modules that might rely on price_extra in product_template_attribute_value?

If this approach is acceptable, would you recommend doing this cleanup in the post-install hook (once) or dynamically in _get_combination_info?

The goal is to ensure the shop display is correct without breaking other module logic.

[NICO-SOLUTIONS]

Two approaches are included in the [DO NOT MERGE] commit:

Temporary:
Sets price_extra to 0 in memory for product_template_attribute_value inside _get_combination_info (does not modify the database).

Permanent:
Post-install hook to set price_extra of product_template_attribute_value to 0 in the database (currently commented out).

Both options are open for discussion. Feedback on which approach to take is welcome.

[eikido18]

I'm up for any solution (I will adapt) but i think the experienced needs to answer this.

@NICO-SOLUTIONS Did you fix the issue where i have to "upgrade" for the module to work? Because i still have to upgrade it seems.

[NICO-SOLUTIONS]

@eikido18
hey. what do you mean exactly with "i have to upgrade"?
When changes have been applied to the module, you need to "update/upgrade" the module to make the changes take effect. Depending on the changes you also have to restart the odoo-server. If the module was installed before....
On fresh installation (module not installed before the changes) it should not appear.
Or what is it that you are referring to?

[eikido18]

@NICO-SOLUTIONS

After the installation, when i try to view a product with variants in the webshop, something crashes (see above and I've also pasted it again below).
To get it working, i need to run "upgrade" of the module.

It doesn't crash for you?
I've tried this many times and on different totally fresh databases. I also just tried cloning your working repository again and made a fresh install.

->

Odoo Server Error

RPC_ERROR
Odoo Server Error

Occured on masked:8069 on 2025-11-17 07:18:33 GMT

Traceback (most recent call last):
File "/usr/lib/python3/dist-packages/odoo/http.py", line 2266, in _serve_db
return service_model.retrying(serve_func, env=self.env)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/odoo/service/model.py", line 184, in retrying
result = func()
^^^^^^
File "/usr/lib/python3/dist-packages/odoo/http.py", line 2313, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/odoo/http.py", line 2528, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/odoo/addons/base/models/ir_http.py", line 357, in _dispatch
result = endpoint(**request.params)
^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/odoo/http.py", line 788, in route_wrapper
result = endpoint(self, *args, **params_ok)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/usr/lib/python3/dist-packages/odoo/addons/website_sale/controllers/variant.py", line 25, in get_combination_info_website
combination_info = product_template._get_combination_info(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/mnt/extra-addons/product_variant_sale_price/models/product_template.py", line 55, in _get_combination_info
for ptav in combination.product_template_attribute_value_ids:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'product.template.attribute.value' object has no attribute 'product_template_attribute_value_ids'. Did you mean: 'product_attribute_value_id'?

The above server error caused the following client error:
RPC_ERROR: Odoo Server Error
RPC_ERROR
at makeErrorFromResponse (http://masked:8069/web/assets/1/6a458f8/web.assets_frontend_lazy.min.js:4554:163)
at XMLHttpRequest. (http://masked:8069/web/assets/1/6a458f8/web.assets_frontend_lazy.min.js:4560:13)

[NICO-SOLUTIONS]

@eikido18
I suggest reverting to the previous version. For Sale/Backend, the module works fine as is.
It seems the crash in the webshop occurs because _get_combination_info from website_sale is called, and our override isn’t applied (the module has no dependency on website_sale).

For Website Sale, a separate optional module should temporarily set price_extra = 0 in-memory for the attribute values of the current combination inside _get_combination_info. This avoids changing the database and only affects the shop display.

Just a question: have you experienced any issues with this in V18? Did it work for you in ecommerce? I haven’t tested it in V18 eCommerce yet. We should get that straight—time is very limited at the moment.

[NICO-SOLUTIONS]

@eikido18
Same behaviour in V18. This is a general issue, not related to migration.
I will keep it like this and we need to handle the website_sale issue in an additional module (e.g., website_product_variant_sale_price).

If attribute values can be set to zero permanently, it’s straightforward and not a big deal.
If we want to keep the extra-prices in the database, it’s a bit more complex, as we need to override price_extra temporarily for the shop. This is because the frontend (website_sale) and QWeb templates rely on the original product.template.attribute.value records for comparisons and rendering. Simply replacing them with temporary objects or dictionaries causes warnings and breaks equality checks. From my point of view, we should keep the values in the database…

Alternatively, the badge can be hidden by modifying the badge view.

So this PR covers ONLY sales, NOT website_sale, as in previous versions.

[NICO-SOLUTIONS]

@eikido18
I need to evaluate which approach makes more sense: either storing the attribute extra prices permanently in the database, or implementing a dynamic solution to handle them in website_sales. Further testing is required to avoid potential conflicts, so I’m not rushing this change yet.

For now, the following is a quick temporary workaround that can be applied manually or as a small standalone module: the badges are simply hidden to keep the website display clean.

<template id="badge_extra_price_hide" inherit_id="website_sale.badge_extra_price">
    <xpath expr="//span[hasclass('variant_price_extra')]/.." position="replace">
        <t t-if="0"/>
    </xpath>
</template>

Please note that this PR applies only to the sales module

[victoralmau]

@eikido18 Currently, in product_variant_sale_price we are NOT setting all product_template_attribute_value.price_extra to 0.

The intention is to ensure the shop does not display old extra prices and that only fix_price is used for variants.

@victoralmau Do you think this could cause any compatibility issues with other modules that might rely on price_extra in product_template_attribute_value?

I am not familiar with this module because I have not used it, although I have never liked the fact that this module sets price_extra to 0 (just an opinion without any context of actual use).

[NICO-SOLUTIONS]

@eikido18 Currently, in product_variant_sale_price we are NOT setting all product_template_attribute_value.price_extra to 0.
The intention is to ensure the shop does not display old extra prices and that only fix_price is used for variants.
@victoralmau Do you think this could cause any compatibility issues with other modules that might rely on price_extra in product_template_attribute_value?

I am not familiar with this module because I have not used it, although I have never liked the fact that this module sets price_extra to 0 (just an opinion without any context of actual use).

@victoralmau
This module provides the flexibility to define fixed prices per variant, which can be significantly simpler and more transparent—especially when dealing with a large number of variants—than relying on price_extra.

Managing pricing via attribute-based surcharges tends to become complex quickly and is often harder to maintain, particularly for non-technical users. In contrast, fixed prices per variant are usually easier to manage and more intuitive from a customer perspective.

That said, I agree that this approach can introduce inconsistencies in eCommerce scenarios. In such cases, a more explicit way to disable or ignore extra prices (e.g., via an additional module) would be an approach.

[OCA-git-bot]

This PR has the approved label and has been created more than 5 days ago. It should therefore be ready to merge by a maintainer (or a PSC member if the concerned addon has no declared maintainer). 🤖