Tuesday, February 11, 2025
19 changes · 17.0
Resolved issues and error corrections
Product images in the wishlist now keep the correct table layout on desktop screens. This fixes a visual border and alignment issue that could make wishlist pages look broken when products have longer descriptions.
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Add 5+ lines to a product's eCommerce description; 2. add this product to your wishlist; 3. open wishlist. Issue ----- The table's border is broken, left of the image. Cause ----- Commit 196f34c6b5271 added the Bootstrap classes `d-none d-md-block` to the table row, in order to hide the image on small devices. The `d-md-block` class cancels out its existing `align-middle` class, which only affects `inline` or `table-cell` elements, not `block` elements. Consequently, the `vertical-align: middle` CSS rule is ignored, leaving the image unaligned on top of the table. Solution -------- Replace `d-md-block` with `d-md-table-cell`. opw-4260090
The product catalog search panel now removes attribute filters that do not match the currently selected category or filters. This prevents users from seeing irrelevant options and makes it easier to narrow down products accurately.
Original PR description
**Current behavior:** In the product catalog, a search Panel is displayed. The user can check filters to find their products. When a category or another filter is checked, the attributes filters are…
**Current behavior:**
In the product catalog, a search Panel is displayed. The user can check filters to find their products. When a category or another filter is checked, the attributes filters are not updated accordingly, even if they are no longer present in the products of the selected category.
**Expected behavior:**
The attributes that do not have a positive count should disappear from the Search Panel.
**Steps to reproduce:**
1. On a blank database, create two products:
1.1 Product A, with category CA and attributes A1 and A2.
1.2 Product B, with category CB and attributes B1 and B2.
3. Go to Sales Order, create a new one and open the product catalog
4. The left search Panel should display the categories CA and CB, and the attributes A1, A2, B1, and B2.
5. Check the category CB.
6. Attributes A1 and A2 are still present.
**Cause of the issue:**
The search Panel JS script is modified by the `product` model, to add the Attributes section. However, the attributes are not filtered based on the selected category, and are always displayed.
**Fix:**
- Add a filtering condition in the `product` model to only display the attributes that have a positive `count`.
opw-4516166
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prPoint of Sale now rounds displayed order quantities consistently to two decimal places. This prevents confusing long decimal values from appearing on order buttons and restaurant floor plan table counters, improving cashier and waiter readability.
Original PR description
Fixed inconsistent rounding of quantities displayed on the order button and table diff counters in the floor plan. **Steps to reproduce the issue:** 1. Add an orderline by clicking on a product. 2. Set the quantity to "2". 3. Click "Order". 4. Click "." and then "2" to adjust the quantity. 5. We can observe really long quantity (not rounded like `0.20000000000000018` instead of `0.2`) **Changes:** - Added `roundQuantity` utility to ensure consistent rounding to 2 decimals. - Applied `roundQuantity` to table diff counters (on floorplan) and order category counters (on the order button inside ProductScreen) . task-id: 4488523 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Adds debug logging for messages exchanged between Tremol fiscal devices and Odoo's local hardware proxy. This helps support teams investigate device communication problems faster when debug mode is enabled, without changing normal user workflows.
Original PR description
Tremol USD device issues can be hard to investigate since we don't have access to all messages exchanged between the device and Odoo drivers. This PR adds logs for request and responses when the debug flag is enable on the proxy server installed on the user computer. opw-4453505
This update makes small corrections to the Swiss payroll ELM transmission area after a recent merge. It helps keep employee and contract payroll data handling reliable, reducing the chance of issues during payroll reporting.
This fixes how Uruguay electronic invoicing report settings are retrieved so custom configurations can be applied correctly. It helps ensure localized electronic documents use the intended report parameters, reducing errors for businesses operating in Uruguay.
Original PR description
ADHOC ticket 85864
This update corrects small setup issues in the Czech 2025 reporting module so tax office lookup, invoice form behavior, and reporting code calculations work consistently. These fixes reduce confusion and help ensure the new reporting module behaves reliably for users.
Original PR description
This commit fixes the following issues of the module l10n_cz_reports_2025: 1. The `tax_office_name` was changed to `name` but that change was dropped in _rec_names_search of the tax office. 2. The readonly attribute was duplicated in account move view. 3. The account_move_line supplies code compute method was different from that of the transaction code (although the logic is identical).
The Belgian payroll meal voucher report now includes the required record identifier. This prevents reporting errors in automated checks and helps keep payroll reporting reliable.
Original PR description
Previously, the database view generated for the meal vouchers report in the Belgian localization didn't have an id which caused an error on the runbot. This commit fixes this issue by generating the id. task-4463505
Miscellaneous changes
Versions -------- - 16.0+ Steps ----- 1. Set up a company located in United Arab Emirates; 2. go to Payment Providers / Stripe; 3. click the Connect Stripe button; Issue ----- > **Validation Error** > Stripe Proxy error: an error occurred while setting up your Stripe account. > Stripe gave us the following information: 'individual' is not a supported business type in the country AE. Cause ----- The initial payload sent to Stripe to connect in live mode is with `business_type
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Set up a company located in United Arab Emirates; 2. go to Payment Providers / Stripe; 3. click the Connect Stripe button; Issue ----- > **Validation Error** > Stripe Proxy error: an error occurred while setting up your Stripe account. > Stripe gave us the following information: 'individual' is not a supported business type in the country AE. Cause ----- The initial payload sent to Stripe to connect in live mode is with `business_type: individual`. This default works for most locales, but for some, e.g. `l10n_ae`, a "registered business" is required. Solution -------- Connect to Stripe using `business_type: company`. This value can still be changed later _after_ entering live mode via `connect.stripe.com`. opw-4545565 Forward-Port-Of: odoo/odoo#197222
Versions -------- - 16.0+ Steps ----- 1. Go to Settings / Website; 2. enable the following options: - Comparison Price; - Pricelists: Advanced price rules; - Prevent Sale of Zero Priced Product; 3. create a pricelist setting all prices to 0; 4. make pricelist selectable; 5. set pricelist's Discount Policy to Show public price & discount to customer; 6. go to `/shop`; 7. query the search bar. Issue ----- A strikethrough price is added, despite the item not being a
Original PR description
Versions
--------
- 16.0+
Steps
-----
1. Go to Settings / Website;
2. enable the following options:
- Comparison Price;
- Pricelists: Advanced price rules;
- Prevent Sale of Zero Priced Product;
3. create a pricelist setting all prices to 0;
4. make pricelist selectable;
5. set pricelist's Discount Policy to Show public price & discount to customer;
6. go to `/shop`;
7. query the search bar.
Issue
-----
A strikethrough price is added, despite the item not being available for sale.
Cause
-----
The `_search_render_results_prices` method still checks for `has_discounted_price` and `compare_list_price` after it already knows the product isn't available for sale.
Solution
--------
If `prevent_zero_price_sale` is given for the product, do an early return, disregarding the `has_discounted_price` and `compare_list_price` options.
opw-4263554
Forward-Port-Of: odoo/odoo#195721As of January 2025, E-Faktur submission is on a new system called Coretax, which requires different file format and content. This commit backports the refactor we did for `l10n_id_efaktur` on 18.0. 4416314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194791
Original PR description
As of January 2025, E-Faktur submission is on a new system called Coretax, which requires different file format and content. This commit backports the refactor we did for `l10n_id_efaktur` on 18.0. 4416314 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194791
When having other modules that depend on the module, if they make an inheritance of the method `_cart_update` like it is on the original method from module `website_sale` (with parameters and then `kwargs`) the inheritance of this module fails, because neither `product_id` nor `set_qty` came on the `kwargs` values instead they came in the `args`.   the inheritance of this module fails, because neither `product_id` nor `set_qty` came on the `kwargs` values instead they came in the `args`.   By inheriting the way the original method is set, it will avoid having to check on the `args` or `kwargs` for the `product_id` and `set_qty` values and use the parameters instead. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#197032
Before this commit here was a discrepancy between getting a report from the Web interface in debug=assets and in debug=0 In debug=assets, some parts of the report were invisible, namely the footer. Following efforts made by 7c4e591d58dd2b882f0c237d52490b2756c94203, this commit forces the PDF rendering in debug=0 mode Some behaviors are left mysterious though. The web.minimal_layout has a <base /> node to make sure every resources is fetched by wkhtml from that origin. It seems that wkhtml
Original PR description
Before this commit here was a discrepancy between getting a report from the Web interface in debug=assets and in debug=0 In debug=assets, some parts of the report were invisible, namely the footer.…
Before this commit here was a discrepancy between getting a report from the Web interface in debug=assets and in debug=0 In debug=assets, some parts of the report were invisible, namely the footer. Following efforts made by 7c4e591d58dd2b882f0c237d52490b2756c94203, this commit forces the PDF rendering in debug=0 mode Some behaviors are left mysterious though. The web.minimal_layout has a <base /> node to make sure every resources is fetched by wkhtml from that origin. It seems that wkhtmltopdf actually makes a fetch request to that raw url with unspecified debug mode. The session being open, ir_qweb is in debug mode anyway, which makes that rpc rendering the main page in debug=assets. For some reason, probably time and memory, that call is responsible for hiding some parts of the report in PDF. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#196138
Steps to Reproduce: * Go to Website --> Edit Mode. * Drag and drop the form snippet. * Click inside the submit button such that the entire label "Submit" is selected. * Press the right arrow key. * The website will become unresponsive. **Changes made:** Assign `previousSelection` with the following properties: `anchorNode: selection.anchorNode` `anchorOffset: selection.anchorOffset` `focusNode: selection.focusNode` `focusOffset: selection.focusOffset` **Reason:**
Original PR description
Steps to Reproduce: * Go to Website --> Edit Mode. * Drag and drop the form snippet. * Click inside the submit button such that the entire label "Submit" is selected. * Press the right arrow key. *…
Steps to Reproduce:
* Go to Website --> Edit Mode.
* Drag and drop the form snippet.
* Click inside the submit button such that the entire label "Submit" is
selected.
* Press the right arrow key.
* The website will become unresponsive.
**Changes made:**
Assign `previousSelection` with the following properties:
`anchorNode: selection.anchorNode`
`anchorOffset: selection.anchorOffset`
`focusNode: selection.focusNode`
`focusOffset: selection.focusOffset`
**Reason:**
The original code attempted to spread the Selection object into previousSelection using **{...selection}**, which is incorrect since **the Selection object is not iterable**. As a result, `previousSelection` was never updated correctly, potentially causing the while loop to run indefinitely.
This fix manually extracts key properties—anchorNode, anchorOffset, focusNode, and focusOffset—from the Selection object and stores them in a plain object. This ensures that previousSelection updates properly, allowing the `hasSelectionChanged` function to function as expected.
By implementing this change, we prevent infinite loops and ensure accurate selection tracking, improving the stability and functionality of the text editor.
task-4471656
Forward-Port-Of: odoo/odoo#194061Those tests were too long and sometimes triggered a timeout when the runbot happened to be too slow. This commit separates each test into its own async function so that the timeout is applied on each test separately, thus significantly decreasing the likelihood of a timeout to occur in any of them. runbot-112694 runbot-112819 Forward-Port-Of: odoo/odoo#196986
Original PR description
Those tests were too long and sometimes triggered a timeout when the runbot happened to be too slow. This commit separates each test into its own async function so that the timeout is applied on each test separately, thus significantly decreasing the likelihood of a timeout to occur in any of them. runbot-112694 runbot-112819 Forward-Port-Of: odoo/odoo#196986
Repro steps: - Add `Tax String` to `Product Page Extra Fields` for one of your websites - Add taxes from a company that isn't linked to that website for one of your products - Open that product's product page in eCommerce - You get an access error The issue is that we try to read the taxes for all companies when opening the product page. Instead, we should only read the taxes for the current company. opw-4435721 Forward-Port-Of: odoo/odoo#194881
Original PR description
Repro steps: - Add `Tax String` to `Product Page Extra Fields` for one of your websites - Add taxes from a company that isn't linked to that website for one of your products - Open that product's product page in eCommerce - You get an access error The issue is that we try to read the taxes for all companies when opening the product page. Instead, we should only read the taxes for the current company. opw-4435721 Forward-Port-Of: odoo/odoo#194881
Before this commit, `hr_skills_tour` used to randomly break in the runbot. The main issue is that it doesn't wait for the new skill to be added before trying to save the form. This commit adds an extra trigger to make sure the skill is added before attempting to save. Runbot Error: https://runbot.odoo.com/odoo/action-573/64575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195860
Original PR description
Before this commit, `hr_skills_tour` used to randomly break in the runbot. The main issue is that it doesn't wait for the new skill to be added before trying to save the form. This commit adds an extra trigger to make sure the skill is added before attempting to save. Runbot Error: https://runbot.odoo.com/odoo/action-573/64575 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#195860
Steps to Reproduce: -> Drag and Drop the Facebook Snippet. -> Click on the snippet. -> Enter any random text. -> The snippet's content is editable. Solution: By adding the `o_not_editable` class to the Facebook Snippet, it prevent user's input from affecting the snippet. This PR ensures that the Facebook Snippet does not accept any user input. task-4517743 Forward-Port-Of: odoo/odoo#195549
Original PR description
Steps to Reproduce: -> Drag and Drop the Facebook Snippet. -> Click on the snippet. -> Enter any random text. -> The snippet's content is editable. Solution: By adding the `o_not_editable` class to the Facebook Snippet, it prevent user's input from affecting the snippet. This PR ensures that the Facebook Snippet does not accept any user input. task-4517743 Forward-Port-Of: odoo/odoo#195549
[FIX] currency_rate_live: Fix BI service API calls failing. This fix adapts our request to the BI service's "unpublished changes" that require a user agent when making a request to their API. opw-4475353 Forward-Port-Of: odoo/enterprise#78362
Original PR description
[FIX] currency_rate_live: Fix BI service API calls failing. This fix adapts our request to the BI service's "unpublished changes" that require a user agent when making a request to their API. opw-4475353 Forward-Port-Of: odoo/enterprise#78362