Thursday, April 2, 2026
8 changes · saas-18.2
Resolved issues and error corrections
This update fixes an issue where the HTML editor toolbar wasn't opening correctly on macOS when using Cmd+Shift+Arrow to select text. The fix utilizes a secondary event listener to ensure the toolbar activates reliably, regardless of the Cmd key's behavior. This improves the user experience for macOS users.
Original PR description
Problem: The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS. Cause: On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar…
Problem:
The toolbar does not open when using Cmd+Shift+Arrow to select text on macOS.
Cause:
On macOS, when the Cmd key is held down, the `keyup` event is never fired for other keys. The toolbar relies on `keyup` for Arrow keys to re-enable `onSelectionChangeActive` and trigger the toolbar update, so it never opens.
See section ("Issue 3 - keyup event put on hold for other keys"): https://web.archive.org/web/20160304022453/http://bitspushedaround.com/on-a-few-things-you-may-not-know-about-the-hellish-command-key-and-javascript-events/
Solution:
Track when an Arrow key is pressed while Cmd is held (`pendingArrowKey`) and use a `selectionchange` listener as a fallback to re-enable the toolbar. The `selectionchange` event fires reliably on macOS even when `keyup` is suppressed. A `isMouseDown` guard ensures the listener does not interfere with the existing mousedown/mouseup flow.
Steps to reproduce:
1- Type some text
2- Use Cmd+Shift+Arrow (left or right) to select text 3- Observe the toolbar does not appear
task-6013408
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253293This update fixes an issue where shipping costs were incorrectly calculated for orders containing combo products. The fix ensures that shipping costs are accurately determined based on the quantity of individual components within the combo, preventing inflated shipping charges. This improves the accuracy of shipping calculations for all customers.
Original PR description
**Issue:**
When using a delivery method that has a shipping cost based on the quantity of the product, the shipping cost is incorrect if there is a combo product. The quantity of the combo product was added to the total quantity of its components.
**How to reproduce:**
1. Create a delivery method based on rules.
2. Create a rule that uses the quantity (ex: 0$ + 5$ times the quantity)
3. Create a combo product
4. Create a sale order and add the combo product to it
5. Add the shipping
=> The shipping cost is incorrect
ex: With 1 combo choice, the shipping cost is doubled
**Fix:**
When calculating shipping cost, skip the sale order line of the combo product and only use the sale order lines of the components.
opw-6016209
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#256055This update fixes an issue where the stock report wasn't accurately reflecting multiple partial returns. Previously, returns could lead to incorrect reporting and duplicate records. This change ensures that returned lots are correctly identified in the report, providing accurate stock visibility for customers.
Original PR description
### Issues: The customer stock.lot.report is not well behaved with respect to multiple partial returns which can lead to returned lots that are not correctly flagged as returned and to duplicate…
### Issues: The customer stock.lot.report is not well behaved with respect to multiple partial returns which can lead to returned lots that are not correctly flagged as returned and to duplicate records. ### Steps to reproduce: - Create a product tracked by SN and put 3 units in stock SN1, SN2, SN3 - Create, confirm and validate a delivery for these two units for Bob. - Click Return, return 1 unit and validate the return for the SN1 - Click Return, return 1 unit and validate the return for the SN2 - Open the contact form of Bob > Lots serial numbers smart button #### > There are two lines referring to SN2 both are flagged as un-returned ### Cause of the issue: In order to determine if a lot has been returned the `stock.lot.report` joins the stock_move_line table with it self based on picking and returns of these: https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock/report/stock_lot_customer.py#L48-L71 Records are then grouped to represent single move lines and a move line is expected to be returned to be returned if it is related to at least one move line on a return of its picking sharing the same lot related data (see the definition of `has_return`): https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock/report/stock_lot_customer.py#L22-L34 Now the issue is that the group by close actually group records based on the `sml_return.id`: https://github.com/odoo/odoo/blob/109f829c2b461b14167e9227e42d096d4410a3b3/addons/stock/report/stock_lot_customer.py#L73-L89 which does not make sense since we expect to aggregate `sml_return.id`'s to compute the `has_return` field and since we do not want a move line of the original delivery to appear twice simply because it is linked to two returns one with and one without returned move line. opw-5974155 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#256396
This update fixes a bug that caused website crashes when users deleted fields within the Helpdesk system. The issue stemmed from how website forms were parsing fields as XML, leading to errors during deletion. The fix ensures that fields are handled correctly during deletion, improving website stability and user experience.
Original PR description
Steps to reproduce ================== tl;dr: html fields are parsed as xml - Go to Helpdesk > Tickets > Warranty - Open studio - Add a new text field named "TEST" - Remove it from the view - Exit studio - Go to the website - Click on new - Add a new blogpost - Set a title and save - Click on "Contact & Forms" - Click on the first block - Click on the form - Change the form action to "Create a ticket" - Click on "+ Field" - Change the Type selection to "TEST" - Click on save - Enable debug mode - Go to "Settings / Technical / Database Structure / Fields" - Type x_ in the search bar and press enter - Delete the field => lxml.etree.XMLSyntaxError Cause of the issue ================== When deleting a field, `_check_if_used_in_website_form` is called to prevent the deletion if a field is used in an html field. The html fields were parsed with an xml parser.. opw-5946029 Forward-Port-Of: odoo/odoo#256066
This update resolves a problem where website assets wouldn't load correctly on replica Odoo instances after a theme change. The fix ensures that the replica receives the latest asset information directly from the primary instance, preventing errors and improving website functionality. This improves the user experience for users accessing Odoo through replicas.
Original PR description
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created…
When `/web/assets/...` is requested on a readonly route and the bundle is missing, Odoo regenerates it on the primary using a RW cursor. It can then still try to read the freshly created `ir.attachment` through the original RO/replica env. In a primary/replica setup, replication may not have caught up yet, so the new attachment is not visible on the replica. As a result, readonly `/web/assets/...` requests can fail right after asset regeneration when fetching the freshly generated bundle. Steps to reproduce: 1. Configure Odoo with a PostgreSQL primary/replica setup. 2. Open a website in edit mode. 3. Trigger an asset regeneration (for example by changing a theme color). 4. Let the resulting readonly `/web/assets/...` request fetch the freshly generated bundle. Build the response stream from the RW env after regeneration instead of rereading the fresh attachment through the RO/replica env. opw-6034833 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255530
This update ensures PEPPOL self-billing invoices accurately include the delivery address and GLN number. Previously, the system wasn't utilizing the delivery address set up within the company, leading to incorrect XML data. This change corrects this issue, ensuring proper data transmission for PEPPOL invoices.
Original PR description
**PROBLEM** When selfbilling with peppol, we have no way of providing a GLN number, or modifying the delivery address. Even if we create a delivery address partner on the current company partner, it's not taken into account. **STEP TO REPRODUCE** 1. Create a delivery address on the current company, set up a GLN number. 2. Configure the purchase journal to do selfbilling. 3. Create a vendor bill with this journal and send it using peppol. 4. Download the xml, and look for the Delivery tag, and notice it doesn't have the GLN number. **FIX** We search for a delivery address on the current company. If there is one, we use it for the Delivery tag. opw-6014374 Forward-Port-Of: odoo/odoo#252970
This update fixes a potential inconsistency issue in the Point of Sale (POS) system. Previously, users could modify tax settings while a POS session was open, leading to discrepancies between receipts and invoices. By adding a safeguard, the system now prevents these changes, ensuring accurate financial reporting.
Original PR description
There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in…
There is a safeguard in account.tax.write prevents modifying taxes as it is forbidden to modify a tax used in a POS order not posted. This guard only applies for a predefined set of fields in account_tax.py. After 18.0, the tax-included behavior is controlled through the `price_include_override` field instead of `price_include`. However, this field was not added in the forbidden fields, allowing users to modify tax inclusion while a POS session is open. This bypasses the safeguard and can lead to inconsistencies, as the POS caches tax configuration at session start. For example, changing this setting mid-session may differences between POS receipts and backend invoices. By adding `price_include_override` to the forbidden fields, the UserError can properly be raised. Additional note: test_fiscal_position_between_frontend_and_backend was updated to close the POS session before changing taxes since the safeguard now correctly blocks this. Related ticket: opw-6042367 Forward-Port-Of: odoo/odoo#254487
This update fixes an error in the Mod 347 BOE export for Spanish companies, ensuring the correct indicators ('C' and 'S') are used for substitutive and complementary declarations. This prevents the AEAT from misinterpreting the file, ensuring accurate tax reporting and compliance.
Original PR description
Currently, the BOE export for `Mod 347` uses incorrect indicators for `Substitutive` and `Complementary declarations`. **Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the…
Currently, the BOE export for `Mod 347` uses incorrect indicators for `Substitutive` and `Complementary declarations`. **Steps to reproduce:** - Install the `l10n_es_reports` module and switch to the `ES company` - Navigate to Accounting > Reporting > Tax Report - From the smart button, select `Report: Tax Report (Mod 347) (ES)` - Download the BOE file using the dropdown. - In the wizard: - Enable `Substitutive Declaration` or `Complementary Declaration` - Set `Previous Report Number` (e.g., 123456789) - Click `Generate BOE` - Upload the generated .txt file to the `AEAT portal`. (AEAT credentials are required) **Observation:** AEAT does not recognize 'X' as a valid indicator for substitutive or complementary declarations and interprets the file as a standard return. **Root Cause:** At [1], the BOE Mod 347 generation writes 'X' for both substitute and complementary declarations. **Fix:** This commit ensures the file contains correct indicators: - 'C' for `complementary declarations` - 'S' for `substitute declarations` This aligns Modelo 347 with AEAT specifications and ensures consistency with the implementation of Modelo 349 at [2]. Ref: https://sede.agenciatributaria.gob.es/Sede/en_gb/ayuda/consultas-informaticas/declaraciones-informativas-ayuda-tecnica/modificar-declaracion-informativa-mediante-fichero.html [1]: https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1061-L1062 [2]: https://github.com/odoo/enterprise/blob/c5332bef593cc3fa1b5013a0dac56ccd67e4da14/l10n_es_reports/models/aeat_tax_reports.py#L1490-L1491 opw-6048711 Forward-Port-Of: odoo/enterprise#112566