Tuesday, March 17, 2026
19 changes · saas-19.1
Resolved issues and error corrections
This update fixes an issue preventing product names from appearing on invoices generated from Point of Sale orders. The change involves a partial revert of a previous fix to ensure the correct product information is displayed without disrupting related widgets. This improves the clarity and accuracy of sales invoices.
Original PR description
Steps to reproduce: ------------------- * Go to point of sale * Open list of orders * Select any order > Traceback Why the fix: ------------ Partially reverting https://github.com/odoo/odoo/commit/937363e5786eeab02b06c2dc63e1d9e743fc1874 as it broke a widget. Pos order are using this widget but the dependency on the field `translated_product_name` makes it impossible to open any order in the backend as this field does not exist on pos order line model. We're only partially reverting the fix to keep the computed fields. This will allow to properly fix the original issue without requiring an exception later. opw-6040334 Forward-Port-Of: odoo/odoo#254158
This update resolves an issue where non-admin users accessing the Accounting Dashboard from a child company with a currency set on the journal would encounter an access error. The fix bypasses specific record rules when a currency is present, ensuring proper access for all users regardless of the journal's currency setting.
Original PR description
Issue before this commit: Opening the Accounting Dashboard from a child company as a non-admin user raises an Access Error when the journal has a currency_id set. The error occurs with journal items which currency id is set Steps to Reproduce ([video](https://drive.google.com/file/d/1Spt5zruNAVAvSdQYk-RuifzynyIfBOLK/view?usp=drive_link )): - Install the account module. - Create child company - Create journal journal with a currency set - Log in as a non-admin user. - Select only the child company - Open Accounting (Dashboard) Cause of the Issue: When the journal does not have currency_id, the system reads company data using sudo(), so no access issue occurs. When the journal has currency_id, sudo() is not used, and reading the company name triggers an Access Error. With This Commit: Bypass record rules when reading the company name if the journal has a currency_id. opw-6017296 Forward-Port-Of: odoo/odoo#253844
This update corrects a typo in the XML format used when sending debit notes to the Italian SDI (electronic reporting system). The original error caused debit notes to be rejected, preventing accurate tax reporting. This fix ensures compliance and proper data transmission.
Original PR description
# Problem:
When sending debit notes to the SDI, they are rejected with the following error:
`File non conforme al formato : Invalid content was found starting with element 'Datifatturecollegate'. One of '{DatiOrdineAcquisto, DatiContratto, DatiConvenzione, DatiRicezione, DatiFattureCollegate, DatiSAL, DatiDDT, DatiTrasporto, FatturaPrincipale}' is expected.`
# Cause:
In the `account_invoice_it_FatturaPA_export_debit_note` there's a typo in 'Datifatturecollegate' as it should be 'DatiFattureCollegate'
https://github.com/odoo/odoo/blob/bc1c264b6232c78c33a96169110b37d9d4430243/addons/l10n_it_edi_ndd_account_dn/data/invoice_it_template.xml#L5-L8
opw-5930596
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#253905
Forward-Port-Of: odoo/odoo#249284This update resolves an issue where manufacturing orders created through the barcode app incorrectly used product UoMs instead of the specified BoM UoMs. The fix ensures that stock moves accurately reflect the BoM quantities, improving the reliability of production planning within the barcode app. This prevents errors and discrepancies in inventory management.
Original PR description
Previous behaviour: * Traceback if MO created with a BoM whose lines have UoMs that don't correspond to those of the products, then UoM setting disabled and MO viewed in the barcode app. * BoM line UoMs ignored in favour of product UoMs when creating MO in the barcode app. New behaviour: * No traceback. * Stock moves in MOs properly created with the corresponding BoM line UoMs. Task ID: [4674196](https://www.odoo.com/odoo/my-tasks/4674196) Forward-Port-Of: odoo/enterprise#110540 Forward-Port-Of: odoo/enterprise#90408
This update resolves an issue where changing a company's VAT setting on Peppol would cause invoices to be rejected by accounting partners. The fix prevents automatic recalculations of EAS/Endpoint values, ensuring invoices are correctly synchronized and avoiding errors. This improves invoice processing reliability for Peppol-registered companies.
Original PR description
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice…
To reproduce: - Register your company on Peppol (even sender). - Change the VAT on your company (will be done if you choose your document layout). - Send an invoice on the network - => The invoice will be refused by the AP. The issue is that the EAS and Endpoint are automatically re-computed when you write on the VAT. It causes issues as the UBL will be filled with the values on the partner, resulting in a non-synchronised SBD and UBL, which will result in all new invoices to be in error. Their only solution would be to revert back the EAS/Endpoint on the partner, which will sometimes be blocked meaning they have to un-register->re-register Also adapt the query count, as we need to do a search in each compute. opw-5923552 opw-5924552 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#253744 Forward-Port-Of: odoo/odoo#249017
This update resolves a crash in the mobile view of the project kanban when adding a 'Blocked By' task. The fix ensures that the system checks for the existence of the parent task before attempting to access its details, preventing a 'Cannot read properties of undefined' error. This improves the mobile user experience and prevents data entry issues.
Original PR description
Currently, opening a task in mobile view and clicking on the 'Add Blocked By' crashes. ### **Steps to reproduce:** 1) Install project app with demo data 2) Open any task from the project, switch to…
Currently, opening a task in mobile view and clicking on the 'Add Blocked By' crashes. ### **Steps to reproduce:** 1) Install project app with demo data 2) Open any task from the project, switch to mobile view 3) Click on the **Blocked By** page and click **Add Blocked By**. ### **Error:** TypeError: Cannot read properties of undefined (reading 'raw_value') ### **Root cause:** The `project_sub_task_view_kanban_mobile` view inherits the base task kanban and removes the `parent_id` field via xpath `position='replace'` at [1]. However, the wrapping `<a>` element with `t-if='record.parent_id.raw_value'` at [2] remains in the template. Since the field is no longer declared, `record.parent_id` is undefined, and accessing `.raw_value` on it causes the crash. [1]- https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/project/views/project_task_views.xml#L759 [2]- https://github.com/odoo/odoo/blob/e602fc2279e85b66c9983741df5d84fab42a3c44/addons/project/views/project_task_views.xml#L704 ### **Fix:** This commit ensures that in the base kanban template, it checks that `record.parent_id` exists before accessing `.raw_value`. **opw-5920660**
A previous change caused an error when starting a new pay run if the date field was left blank. This fix ensures the system validates the date field before processing, preventing the 'value.toFormat is not a function' error. This ensures users can consistently initiate pay runs.
Original PR description
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` >…
Currently, an error occurs when a user starts a new pay run. Steps to Reproduce: - Install `l10n_hk_hr_payroll_empf` module with demo data. - Switch to the `Hong Kong` company. - Go to `Payroll` > `Payslips` > `Pay Runs`. - Click `New`, remove the `period value`, and click `Continue`. `TypeError: value.toFormat is not a function` After this recent [commit] that changed the required field validation behavior, when the date field is empty and it attempts to serialize the date [1], which raises the error here [2]. Although the start and end date field is required, the ORM call is executed without the value for the date field. This commit ensures that, similar to the base PayslipBatchFormController [3], the fields are validated before making the ORM call. [commit]: https://github.com/odoo/enterprise/commit/cd0f5f31e9427cb96092671bbcbb52dfbb3c03f8 [1]- https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/l10n_hk_hr_payroll_empf/static/src/views/payslip_run_form/hr_payslip_run_form.js#L13-L14 [2]: https://github.com/odoo/odoo/blob/3263a7f54948d57f13176cf0416b1419150e9d87/addons/web/static/src/core/l10n/dates.js#L536 [3]: https://github.com/odoo/enterprise/blob/431d1b513f26188f693abd949f78a893514205f0/hr_payroll/static/src/views/payslip_run_form/hr_payslip_run_form.js#L16-L20 sentry-7207509338
This update resolves an issue where users on Firefox couldn't hear incoming calls. The fix ensures that call tracks are processed immediately upon arrival, regardless of the session establishment timing. This improves the Odoo VoIP functionality for Firefox users.
Original PR description
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the…
Steps to reproduce the bug: - Install voip and open the Odoo backend on Firefox - Setup your voip settings - Call your softphone number, thanks to your smartphone - Once the softphone opens with the call, answer => The caller can hear you but you cannot hear the caller. This happens since [1]. Before that commit, we had something like "when the session is established, listen to tracks being added to the call and also set up the audio". After that commit, this became "when the session is established *or is establishing*, listen to tracks being added to the call... *but don't set up the audio otherwise*". The problem is that on Firefox, the timing is such as the tracks of incoming calls are being added just before the session is establishing (or established), meaning we listen to tracks being added too late. Note that commit [1] was further diluted afterwards by commits like [2] (doing stuff with the audio before establishing) and [3] (which simply removed the "established" part, relying on "establishing" being done). Later on, commit [4] prepared some other work by moving and improving things around and it actually fixed this issue here by chance. What did the trick is listening to tracks being added from the start: as soon as SIP.js notifies that the remote stream exists. This commit fixes the issue in impacted versions (19.1 and 19.2) by backporting the relevant part: listening to tracks being added as soon as possible and not once establishing/established. A test was added. [1]: https://github.com/odoo/enterprise/commit/d24d7f3406ca47e7ac529d69957b0ad481d553bf [2]: https://github.com/odoo/enterprise/commit/71d78810ae7f6c9169912276da18e04ad4f7bef0 [3]: https://github.com/odoo/enterprise/commit/942f32316ab02d8c739fe7fdd5ec2bdde472a68e [4]: https://github.com/odoo/enterprise/commit/33fc327c1c74ee874d546a98879dbbf468809850 task-5902700
This update resolves an issue where the mobility budget calculation in the Belgian HR contract module was not functioning correctly when the page initially loaded. The fix ensures that the budget is accurately displayed, improving the accuracy of payroll processing for employees relocating within Belgium. This impacts the correct calculation of employee compensation.
This update resolves an issue where the Odoo system was sending incorrect data to Mollie for payment processing. Specifically, when a customer's address information was incomplete, Odoo was generating an error. The fix adds default empty strings to address fields, ensuring Mollie receives valid data and payment transactions can proceed smoothly.
Original PR description
When a partner has no country (or other address fields) set, accessing `partner_country_id.code` (and similar Char fields) returns `False` in Odoo instead of an empty string. This caused Mollie's API to return a 422 error because it expects a string for `billingAddress.country`. Add `or ""` fallbacks to all string fields in `_mollie_prepare_billing_address_payload` to ensure valid JSON types are always sent. opw-6037640 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where currency rates were being used retroactively in certain reports (CTA queries). Now, reports will use the correct, same-day currency rate, ensuring more accurate financial reporting and analysis. This improves the reliability of key business reports.
Original PR description
We use currency rate at day x - 1 to be applicable at a date x, which shouldn't be applicable in the cta queries. Use same-day rate for the CTA query. task-5969168
This update resolves a problem where combo prices were incorrectly doubling when multiple items were ordered during pricelist updates. The fix ensures that free items are scaled correctly and that parent unit prices are accurately updated, leading to more reliable combo pricing in the Point of Sale system. This improves the accuracy of sales calculations and prevents overcharging customers.
Original PR description
Fix combo prices doubling when quantity > 1 during pricelist changes. Correctly scale free items in 'getFreeAndExtraChildLines' and ensure parent unit prices are updated in 'setPricelist'. task-id: 5971935 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update automatically groups vendor bills during UBL/CII import based on the vendor's previous bill activity. The system now checks the last posted bill to determine if lines should be grouped by tax, streamlining the import process and reducing manual adjustments. This improves data accuracy and efficiency for invoice processing.
Original PR description
[FIX] account_edi_ubl_cii: automate bill line grouping
This commit automates vendor bill line grouping during import based on the vendor's most recent posted bill.
- Logic: Added `_has_lines_grouped()` to `account.move` to detect if lines follow the grouping pattern.
- Heuristic: During UBL/CII import, the system now checks the last posted bill from the same vendor; if it was grouped, the new bill is automatically grouped by tax.
task-5979667
Forward-Port-Of: odoo/odoo#253322
Forward-Port-Of: odoo/odoo#251419This update fixes an issue where leave hours weren't being calculated correctly for allocations without end dates. The change broadens the allocation timeframe to start from the earliest start date, ensuring accurate tracking of leave hours across all allocations, regardless of their expiry dates. This improves the reliability of leave balance reporting.
Original PR description
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after…
### Steps to reproduce: - Create a Overtime hours time off type - Create mutliple allocations with different start dates but no end date - Create some leaves for the created allocations one after each allocation start date - Compare the number of hours remaining for the allocations' employee in his time off dashboard and in the Balance report. ### Cause: After this commit https://github.com/odoo/odoo/pull/245860/changes/d9bb4d206e91d10eac7311adede307b8c5019213 we changed the way we match leaves with allocations but we were strict that the leave has to lie in between the allocation dates and this created a wrong accumlated taken_hours in the taken_per_allocation subquery. ### Fix: Following the same approach we use in if the allocation has no expiry date we don't check if the leave.date_to > allocation.date_from as we are going to treat all allocations as they form one big allocation that started in the earliest start date opw-5474596 Forward-Port-Of: odoo/odoo#253831 Forward-Port-Of: odoo/odoo#250432
This update corrects a performance issue in the budget report, ensuring faster execution times. Previously, an installation of the account_budget_purchase module was causing slow report generation due to a bypassed optimization. This fix restores the intended performance improvement.
Original PR description
The performance optimization introduced in account_budget (see PR #99096) pushes the budget_line_ids filter down to the underlying SQL queries of budget.report to avoid building the full UNION result before applying the filter. account_budget_purchase fully overrides budget.report._compute_all() and its table_query, thereby bypassing the optimized implementation introduced in PR #99096. As a result, the budget_line_ids filter was not pushed down to the SQL level, causing large UNION queries to be executed without filtering and leading to degraded performance. Apply the same optimization in this module to restore the expected performance improvement when account_budget_purchase is installed. | Scenario | Execution Time | | :--- | :--- | | **Before this Commit** | **passed virtual time limit** | **After this Commit** | **1.25 seconds** opw-5930127 Forward-Port-Of: odoo/enterprise#109322
This update resolves an issue where serial numbers weren't being generated correctly using date-range sequences. The fix ensures that each new receipt creates a unique serial number within the specified date range, improving inventory tracking accuracy. This change was implemented by refining the sequence update logic during lot generation.
Original PR description
### Steps to reproduce: - In the settings enable: Lots & Serial Numbers and Multi-Step routes - Settings > Technical > Sequences & Identifiers > Sequences - On the stock.lot.serial sequence enable:…
### Steps to reproduce: - In the settings enable: Lots & Serial Numbers and Multi-Step routes - Settings > Technical > Sequences & Identifiers > Sequences - On the stock.lot.serial sequence enable: `Use subsequences per date_range`, add a range date containing today - Create a product tracked by Serial numbers - Create and confirm a receipt for 3 units of your product - Detailed of the move > Generate Serials/Lots > New > Generate #### > 3 serial numbers were created but the date specific sequence has only been updated once. This can be checked by creating a new receipt and processing the same exact flow. ### Cause of the issue: Generating the serial numbers will call the `action_generate_lot_line_vals`. However, this method is not tailored to deal with the `use_date_range` and increments the main sequence rather than the actual subsequence: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/addons/stock/models/stock_move.py#L1103-L1106 ### Fix: We rely on the apparently unused `_get_current_sequence` method to recover the appropriate sequence by date range to update: https://github.com/odoo/odoo/blob/441a6d1b928a44b9a760f926180a925159edff3e/odoo/addons/base/models/ir_sequence.py#L114-L128 This method has been introduced in an accounting naming IMP: 915aa9e4db3169a4767617b5310721f0d9c16812 and is unused since the accounting is no more relying on name sequences: dfd01b8c5c7e1177f37bf199790a0732a61eed78 In addition, we fine tune the current version of the code updating the serial sequence on lot generation since it is currently updating the sequence only if the first generated lot has been set via the`New` button and hence has incremented the sequence via a `next_by_id` call: https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/lots_dialog.xml#L33 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/addons/stock/static/src/widgets/generate_serial.js#L48-L56 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L261-L275 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L335-L337 https://github.com/odoo/odoo/blob/ec9343376597a4bffe9d2fd2f68777fe11b93267/odoo/addons/base/models/ir_sequence.py#L53-L55 While if the value of first lot is given manually to the wizzard is given manually to the wizzard, the sequence does not get incremented by the nextval. opw-5931056 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253618
This update fixes an issue where backorders were incorrectly doubling labour costs in the accounting system. When ‘Create Backorder’ is always enabled, a process triggered a duplicate labour entry. The fix ensures labour costs are recorded only once per backorder work order, preventing inaccurate accounting and maintaining data integrity.
Original PR description
When the Manufacturing operation type is configured with Create Backorder = Always, `mrp.production.pre_button_mark_done()` re-enters `button_mark_done()` in the same server execution path. This can trigger `_post_labour()` twice, causing two posted “<MO> - Labour” journal entries and doubling labour costs in Accounting. Labour costs should be posted only once per workorder time entry. Ensure labour is only posted once by skipping workorder times that were already linked to an accounting entry. This prevents a second execution from creating a duplicate labour journal entry. A test was added to cover the partial production flow when backorder is set to “Always.” Related ticket: opw-5931754 --- Forward-Port-Of: odoo/odoo#253689 Forward-Port-Of: odoo/odoo#250237
The planned removal of the older RPC service (xmlrpc) has been delayed until Odoo 21.1 or 22. This change ensures continued support for Odoo 20, 21, and 22 under the standard support policy, maintaining existing functionality and avoiding disruption for users.
Original PR description
The "rpc service" API (xmlrpc/jsonrpc) have been deprecated in 19.0, JSON-2 acting as replacement. It was at first planned to be removed in 19.1/20 but we succeeded in convicing the management It Was…
The "rpc service" API (xmlrpc/jsonrpc) have been deprecated in 19.0, JSON-2 acting as replacement. It was at first planned to be removed in 19.1/20 but we succeeded in convicing the management It Was A Bad Idea. The removal is postponed to Odoo 21.1/22. This makes so that if the [Standard and extended support] policy remains the same until the release of Odoo 22, all versions supported with no additional fees (20, 21, 22) at that time will have JSON-2: | version | supported at 22 release | rpc services | JSON-2 | | ------- | ----------------------- | --------------------- | ------ | | 18.0 | no[^1] | active | absent | | 19.0 | no[^1] | active but deprecated | active | | 20.0 | yes | active but deprecated | active | | 21.0 | yes | active but deprecated | active | | 22.0 | yes | absent | active | [Standard and extended support]: https://www.odoo.com/documentation/19.0/administration/standard_extended_support.html [^1]: with no additionnal fees. Forward-Port-Of: odoo/odoo#252721
This pull request addresses several issues related to the processing of physical cards through Stripe in the Odoo Enterprise system. Specifically, it fixes problems with UK card handling, improves test coverage, and enhances logging for easier debugging. These changes ensure accurate and reliable processing of UK expense reimbursements.
Original PR description
Forward-Port-Of: odoo/enterprise#110263