Monday, March 23, 2026
12 changes · 17.0
Enhancements to existing features
This update enhances Odoo's debugging capabilities by capturing detailed Chrome logs, particularly when Chrome tabs unexpectedly terminate. These logs provide more specific information than previous error messages, aiding in identifying and resolving stability issues. Administrators can control the level of logging through a new environment variable.
Original PR description
Followup and partial revert of #232612: turns out chrome's stderr is worthless at best and confusing at worst (because it logs a bunch of dbus errors which don't actually matter), however chrome…
Followup and partial revert of #232612: turns out chrome's stderr is worthless at best and confusing at worst (because it logs a bunch of dbus errors which don't actually matter), however chrome turns out to have pretty extensive debug logging facilities which are somewhat valuable: https://www.chromium.org/for-testers/enable-logging/
For instance if the oomkiller decides to nuke a chrome tab (example selected for no reason whatsoever), the debug log will have an entry along the lines of
[...:WARNING::chrome/browser/ui/sad_tab.cc:256] Tab Killed: http://127.0.0.1:8069/
which is a much more helpful hint than just being told a test timed out (to say nothing of being told that chrome was not able to do dbus stuff when we never asked for that).
Because it can be useful for all sort of debugging, this log is saved not just when chrome fails to start, but also when a Chrome completes, successfully or unsucessfully (in the latter case it's logged as RUNBOT to be available from the runbot UI).
The chrome logging facilities are controlled by a new envvar `ODOO_BROWSER_LOG_VERBOSITY`, it can be set to `-1` to disable logging, or a strictly positive integer for ever increasing amounts of logging. At `1` chrome will log every network request it attempts which can be useful for debugging some races but is already extremely noisy.
Forward-Port-Of: odoo/odoo#255054Resolved issues and error corrections
This update automatically calculates and transmits the necessary commission payments for Swiss payroll (ELM) declarations. Previously, this calculation was manual, and this change streamlines the process, ensuring accurate and timely reporting to tax authorities. This improves compliance and reduces the risk of errors related to commission calculations.
Original PR description
task-6050810
This update resolves a bug preventing users from correctly changing the 'Recurring' status on subscription products with existing sales orders. The fix ensures the change is reverted properly, preventing incorrect data and improving data integrity. This update impacts subscription management functionality.
Original PR description
**Problem:** When attempting to change "Recurring" on products in the form view, if there are confirmed SOs, the change should be reverted and a message should appear explaining this. However, there is a bug in how the change is reverted where it takes the current form value of the field. This cannot be trusted as it's possible to trigger another onchange before the first one resolves, so the second onchange is based on the wrong value. **Steps to Reproduce:** - w/Demo Data, go to product "Office Cleaning Service (SUB)" (This is a subscription product which has confirmed SOs) - Quickly click the checkbox for "Recurring" twice -> Two warnings appear, but Recurring is False and can be saved **Solution:** Instead of reading the current form value and setting its opposite, we can revert to the current value on the server.
This update fixes an issue where the SDWorx payroll report didn't account for public holidays. The change ensures that employee attendance is correctly calculated, including days when the company is closed for holidays, leading to more accurate payroll reporting.
Original PR description
### Steps to reproduce: - Setup a public holiday in a month January for example - Add a leave for an employee for the whole Month of January - Export the SDworx report - Notice for the day of the public holiday, it is shown as a normal attendance ### Cause: When checking leaves for the SDWorx report we only check hr.leave we don't check resource.calendar.leaves ### Fix: We take resource.calendar.leaves now into account to make sure we add public holidays to the report when exporting it opw-5500070
This update resolves an issue where scanning a barcode with a different serial number than the reserved one didn't create a new lot in stock. The fix ensures that the correct lot is always used when scanning in batches, preventing incorrect inventory tracking. This improves the accuracy of stock management.
Original PR description
Issue ----- When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken…
Issue
-----
When processing batches in barcode, scanning a BC with a different SN than the reserved one does not lead to creating a new lot in stock. The reserved one is still the one getting taken regardless of setting.
Steps to reproduce
-----
- Enable GS1 nomenclature, lots & batches
- Go to Inventory > Configuration > Operation Types > Delivery Orders
- Enable Lots/Serial Numbers > Create New
- Create a product
- Barcode 23456789012344
- Tracked by SN
- 1 in stock (SN 1234)
- Create a delivery for the product and add it to a batch
- Open the batch in barcode
- Scan 012345678901234410BATCHSN1
- Confirm the delviery
- Go back to the picking and see the lines' details
> The line used the reserved SN
Cause
-----
The existing line gets matched in `_findLine`
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1085
because none of the conditions before
https://github.com/odoo/enterprise/blob/45d3a537c3b2eaccee425d959e89d26229e376cd/stock_barcode/static/src/models/barcode_model.js#L1402
get matched. This is unexpected but necessary for batches, as it ensures barcode correctly swaps to the correct picking in the batch. If the line was not matched we would be creating a new line in the same picking than the last scanned line, regardless of which picking the reservation is made in.
Because a line is matched, we have to force its' `lot_id` to `false` so that the new one gets created (`lot_name` is used for display but `lot_id` takes precedence).
-----
Ticket:
opw-5216921This update optimizes how Odoo searches for products during the 'explode' process, which is a key step in managing product components. By batching database queries, the change reduces the time spent on this process, resulting in faster product searches. This improvement primarily impacts the MRP module.
Original PR description
When searching product based on the qty_available field, a lot of time is spent in explode() calls. In the explode() method, we call _bom_find() for each bom involved. This method only depends on the picking_type_id and company_id of the bom. Thus we could batch it and call the method once per tuple (picking_type_id, company_id). Benchmark: |No BoM | No product variants | Before | After | |-------|------------|--------|-------| | 1700 | 13000 | 80s | 40 s | opw-6017527 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update corrects a validation issue that occurred when using Recupel tax on invoices with negative line items. The fix ensures that the generated XML invoices correctly represent the tax treatment, preventing validation failures. This ensures compliance with PEPPOL standards and accurate invoice processing.
Original PR description
**PROBLEM** If you set a recupel tax (fixed tax affecting base) and use it on a negative line, the generate xml will not pass validation. **STEP TO REPRODUCE** 1. Setup Peppol. 2. Create a recupel tax (fixed tax of 1€, affecting the base). 3. Create an invoice with a negative line, with a VAT and the recupel tax. 4. Send the invoice using peppol, and validate the xml. 5. Notice the xml doesn't pass validation. **CAUSES** 1. The negative fixed tax should be an allowance, but is marked as a charge in the xml. 2. Only fixed taxes that are charges influences the line_extension_amount, but it should also be the case with negative fixed taxes. 3. Negative fixed taxes should have a ChargeAllowanceReasonCode that is in the AllowanceReasonCode list. opw-5955289 Forward-Port-Of: odoo/odoo#252716
This update fixes an issue where exchange differences weren't correctly recorded when receiving billed products with fluctuating exchange rates. Specifically, it ensures exchange difference journal entries appear in the correct account when a negative exchange rate applies after a bill has been created. This ensures accurate financial reporting.
Original PR description
Issue ----- When receiving product after having billed it already, if: - the product is valuated, - the purchase is in a foreign currency, - there is an underlying exchange diff between time of bill…
Issue
-----
When receiving product after having billed it already, if:
- the product is valuated,
- the purchase is in a foreign currency,
- there is an underlying exchange diff between time of bill and reception
- the diff exchange rate is negative
then the exchange difference account move will occur in the regular exchange account.
Steps to reproduce
-----
- Enable automatic (anglo-saxon) accounting & dropshipping
- Enable the EUR currency and add 2 exchange rates
- today with 2:1 (EUR:USD)
- yesterday with 1:2 (EUR:USD)
- Create a new AVCO product category
- costing method: AVCO
- valuation: automatic
- Create a new product
- type: storable
- category: AVCO
- purchase: 5€
- set dropship route
- Create and confirm a SO
- Confirm PO and validate delivery
- Create bill for the PO
- change bill date to before yesterday & confirm
> Journal entry created in "Exchange Difference" journal
Cause
-----
Thanks to commit 80ff2d2 the flow is well behaved if the new rate is higher (company currency worth more comparatively) because we use the credit aml
https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/addons/account/models/account_move_line.py#L2214-L2215
whose move has a svl
https://github.com/odoo/odoo/blob/b57bb1decd46dcbb1fe602bb72b6f8e5382e9b28/addons/stock_account/models/account_move.py#L335
This is not the case for the debit aml, so we end up using the default currency exchange account.
-----
Ticket:
opw-4797287This update resolves a bug where changing the packaging quantity in a quotation unexpectedly altered the calculated product quantity and packaging amount. The fix removes a dependency causing incorrect calculations, ensuring packaging quantities update accurately when adjusting the main quantity.
Original PR description
**Behaviour:** When creating a sale order line for an item with multiple packagings, modifying the packaging quantity will trigger the computation of the product quantity which will trigger the…
**Behaviour:** When creating a sale order line for an item with multiple packagings, modifying the packaging quantity will trigger the computation of the product quantity which will trigger the computation for the packaging itself. This creates a dependency between the chosen package and the quantity selected which can end up triggering unexpected reactions when following specific flows. **Steps to reproduce:** - Enable packages for sales in configuration - Create a product, in the inventory tab, add two packages: Pack of one, and Pack of four and set corresponding unit. - Create a quotation and set the SO line to Quantity to one, this should set Packaging and Packaging Quantity to 1 aswell - Now change Packaging Quantity to 4, this should visually only change the Quantity to 4 - Now if you change Quantity to 5, you should see Packaging switch to packs of 4 and Quantity jump to 20. This is caused because when in` _compute_product_uom_qty` we try to get the `product_packaging_id` which in turn triggers `_compute_product_packaging_id `before completing the previous compute. https://github.com/odoo/odoo/blob/cf9805874722b6729b5301fdea4f107ae221a1d2/addons/sale/models/sale_order_line.py#L397-L411 When we change the packaging_qty to 4, the packaging_id doesnt change as the compute is triggered before assigning 4 to the uom_qty. But when we change packaging_qty to 5, the packaging_id changes to packs of 4 as the compute is triggered before the uom_qty should go to 5 which then results in the uom_qty switching to 20. The solution removes the dependency between package_id and qty.
This update resolves an issue preventing the export of self-billing invoices when using the Factur-X (CII) electronic invoicing format. The fix addresses a missing function within the invoicing process, allowing users to correctly generate self-billing invoices for Factur-X invoices. This ensures seamless integration with Peppol Self-Billing.
Original PR description
# How to reproduce - Install the Peppol Self-Billing module (account_peppol_selfbilling) - Go to any contact - In the accounting tab, set the Electroing Invoicing to "Factur-X (CII)" - Try to access…
# How to reproduce
- Install the Peppol Self-Billing module (account_peppol_selfbilling)
- Go to any contact
- In the accounting tab, set the Electroing Invoicing to "Factur-X (CII)"
- Try to access any Vendor Bill
# The problem
A traceback is shown
# Why
This commit (https://github.com/odoo/odoo/commit/c696a11ee735b0689ef6a00f1a189916724d4854) backported the peppol self-billing feature.
When the user try to access a Vendor Bill, this check is run :
```py
def _is_exportable_as_self_invoice(self):
return (
self.state == 'posted'
and self.is_purchase_document()
and self.commercial_partner_id.ubl_cii_format
and (edi_builder := self.commercial_partner_id._get_edi_builder()) is not None
and edi_builder._can_export_selfbilling()
and self.journal_id.is_self_billing
)
```
In the case of Factur-X invoicing (account.edi.xml.cii), ```_can_export_selfbilling()```is not defined.
opw-6022938
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where leave hours weren't accurately calculated when employees used calendars with multiple defined dates and times. Previously, the system didn't properly interpret complex calendar schedules, leading to incorrect leave start and end times. This change ensures that leave hours align precisely with the defined calendar events, providing accurate leave tracking.
Original PR description
Define the correct hours in the leaves if the calendar has defined dates (`date_from` and `date_to`) Use case example: - Create a calendar and define on Friday (Morning: from 08:00 to 13.00,…
Define the correct hours in the leaves if the calendar has defined dates (`date_from` and `date_to`) Use case example: - Create a calendar and define on Friday (Morning: from 08:00 to 13.00, Afternoon: from 19:00 to 21:00) with date_to=2025-01-01. - Define another specific Friday (Morning: from 09:00 to 14.00, Afternoon: from 17:00 to 20:00) in the same calendar with date_from=2025-01-01. - Create an employee and define the calendar created for him/her. - Create a leaves for the employee and select a Friday (2025-05-02). - The start hour of the leave must be 2025-05-02 09:00:00 - The end hour of the leave must be 2025-05-02 20:00:00   Please @pedrobaeza can you review it? @Tecnativa TT56218 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208378
This update ensures that attachment files are always linked to a financial transaction simultaneously. Previously, updating the transaction details and attaching a file could lead to inconsistencies. This change guarantees data integrity and prevents errors when sending RS EDI documents.
Original PR description
Was committing the move fields update, then updating the attachment. This might create an issue were the move update commits successfully, but setting the attachment fails and we end up with an inconsistency. Set attachment in the same transaction as the move update. task-6035727 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr