Monday, March 30, 2026
21 changes · saas-18.3
Resolved issues and error corrections
This update prevents a critical error that occurred when users attempted to create scrap orders without a designated scrap location. The issue stemmed from accessing an empty dictionary after a scrap location was deleted, leading to a traceback. This fix ensures that scrap orders can now be created successfully, regardless of the scrap location setup.
Original PR description
When user tries to create a scrap order without scrap location, A traceback is raised. Steps to reproduce the error: - Install ``stock`` module - Go to Inventory > Configuration > Settings > Enable Storage Locations > Save - Go to Configuration > Locations > Delete Virtual Locations/Scrap > Delete - Go to Operations > Scrap > New Traceback: ```py KeyError: 1 ``` https://github.com/odoo/odoo/blob/7d89c092ac25ffe149fb38fb52863fdaa3b6ed5f/addons/stock/models/stock_scrap.py#L93 When the Scrap location is deleted, ``locations_per_company`` becomes an empty dictionary. Accessing a key from this empty dictionary lead to the above traceback. sentry-7307394327 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252192
This update corrects an issue preventing the export of Profit & Loss reports with footnotes in the Luxembourg localization. The previous export process relied on an outdated model, causing errors. The fix now correctly utilizes the new `account.report.annotation` model for footnote references, ensuring successful XML generation.
Original PR description
**Steps to reproduce:** * Install the **l10n_lu_reports** module. * Go to **Accounting → Reporting → Profit & Loss**. * Add a footnote on a report line (**⋮ → Annotate**). * Click **Export (XML)** to open the export wizard. * Enable **Import notes as references** and export. **Observed behavior:** * Export fails with `KeyError: 'account.report.manager'`. * XML file cannot be generated when references are enabled. **Cause:** * The export logic relied on the deprecated `account.report.manager` model. * This model was removed in v17([commit](https://github.com/odoo/enterprise/pull/33604/changes#diff-5fc5051f5c0211c0eec96b892e7d29e01b68d804417443502d17bccd8333d7ecL41)) and replaced by `account.report.footnote`. * The footnote retrieval code was not migrated accordingly. **Fix:** * Migrate reference retrieval to use `account.report.footnote`. opw-5890630 Forward-Port-Of: odoo/enterprise#111845 Forward-Port-Of: odoo/enterprise#107765
A recent update caused partner names in the approval request report to overflow, making the report visually unclear. This fix adds a column limit to the partner field, ensuring all data is displayed correctly and preventing the report from becoming unreadable. This improves the report's usability and data accuracy.
Original PR description
step to reproduce: - install "approval" with demo data - have a partner with name length > 63 - open one of the approvals and change its type to "general approval" - add this partner in contact field - print approval request report Observation: - the partner overflows out of report Fix: - we limit the partner field with `col-9`. For a safe measure i have added `col-9` for `request_owner_id` and `approver_ids` **Before** <img width="1057" height="326" alt="image" src="https://github.com/user-attachments/assets/a8eea789-5cc7-4658-88b5-78751759d043" /> **After** <img width="994" height="330" alt="image" src="https://github.com/user-attachments/assets/bfbc061b-a6e0-4593-a3cc-c85cb81db6e2" /> opw-6005752 Forward-Port-Of: odoo/enterprise#111130
This update fixes an issue where invoices created with the 'Pay Later' payment method in the Point of Sale module were missing the necessary QR code for payment. The fix ensures that invoices correctly identify the bank partner, resolving this problem and allowing for proper payment processing. This improves the user experience for customers using this payment option.
Original PR description
Step to reproduce: - Install l10n_ch_pos and make sure swiss company has tax id filled - Create a swiss customer with an email address and vat, add full address - Open a pos session, and make an invoice for a product with tax, - select payment method, which allows `pay_later`, i.e. payment without journal_id Observation: - the invoiced order, do not have qr for payment, because the invoice do not have `bank_partner_id` Cause: - `_get_partner_bank_id` is recently updated in commit[1], which do not considered `pay_later` option [1] https://github.com/odoo/odoo/commit/7e63991dceb6e443b950e6a1b94454a82d5668c7 Fix: - Fixed the fallback logic for `_get_partner_bank_id` opw-6023060 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#254892 Forward-Port-Of: odoo/odoo#254117
This update ensures that when creating new analytic items from the gross margin smart button, the correct analytic account is automatically selected. Previously, new records didn't link to an account, requiring manual setup. This change streamlines the process and improves data accuracy within the analytic accounting module.
Original PR description
When accessing analytic items from the gross margin smart button on an analytic account, creating a new record does not pre-fill the analytic account field. This happens because the context does not set `default_account_id` for the active analytic account, leading to newly created lines not being linked at creation time. This commit ensures the analytic account is correctly passed through the context, so it is automatically set when creating a new analytic line from this flow. Steps to reproduce: - Open an analytic account - Click on the gross margin smart button - Create a new analytic item Before: analytic account not set by default After: analytic account is pre-filled via context task-3909624 Forward-Port-Of: odoo/odoo#256091 Forward-Port-Of: odoo/odoo#255726
This update fixes an issue where chatbot restart messages were incorrectly included in new ticket or lead descriptions. Now, only messages sent after the chatbot is restarted are accurately reflected, ensuring ticket descriptions are clean and relevant. This improves the clarity and usability of customer support tickets.
Original PR description
Before this commit: When a chatbot conversation is restarted and the script creates a new ticket/lead, the description also includes messages from the previous session. After this commit: Only the messages sent after the chatbot conversation is restarted are included in the ticket/lead description. Task-5118966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#255336 Forward-Port-Of: odoo/odoo#253566
This update replaces the old iDEAL logo with the new Wero logo for improved brand consistency. The change ensures that customers see the correct payment brand when using the iDEAL payment method within Odoo, enhancing the user experience.
Original PR description
Before the commit: The iDEAL payment method was using the existed legacy iDEAL logo. After the commit: - Updated the display name to "iDEAL / Wero". - Replaced the legacy iDEAL logo with the new Wero logo. - Introduced a separate "Wero" payment brand. task-5922938 Forward-Port-Of: odoo/odoo#254901 Forward-Port-Of: odoo/odoo#248506
This update resolves an issue where the tax report incorrectly flagged inconsistencies when vendor bills had expense lines with different vehicle assignments. The fix allows for accurate reporting when lines share a tax but have varying vehicle IDs, ensuring consistent tax calculations for all expenses.
Original PR description
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other…
**Steps to reproduce:** * Install the **account** and **fleet** modules. * Create a vendor bill with two expense lines using the same tax. * Assign a vehicle_id to one line but leave the other without a vehicle. * Confirm the vendor bill. * Go to **Accounting > Reporting > Tax Report** and Go to `Account > Tax` report. **Observed behavior:** * The tax report shows: 'This report contains inconsistencies. The affected lines are marked with a warning.' **Cause:** * The `_get_extra_query_base_tax_line_mapping()` override forced vehicle_id matching using `COALESCE(base_line.vehicle_id, 0) = COALESCE(account_move_line.vehicle_id, 0)`. * When lines share a tax but have different vehicle_id values (one set, one NULL), Odoo creates a single tax line with `vehicle_id = NULL`. * The strict COALESCE constraint prevented this tax line from matching either base line (NULL ≠ vehicle_id and NULL ≠ NULL when coalesced to 0), causing the inconsistency. **Fix:** * Changed the constraint to only enforce vehicle_id matching when both the base line and tax line have a vehicle_id set. * If either side is NULL, the match is allowed, letting shared tax lines work correctly across mixed vehicle/non-vehicle expense lines. opw-5956645 Forward-Port-Of: odoo/enterprise#112313 Forward-Port-Of: odoo/enterprise#110616
This update ensures that the system correctly checks archived accounts when creating unaffected earnings accounts. Previously, this caused validation errors, particularly during upgrades with the `l10n_sa` module, due to a search for duplicate account codes including archived ones.
Original PR description
Archived accounts are also searched when looking for duplicate codes since https://github.com/odoo/odoo/commit/cd8d9718427e48aaa79be21f9a08e89b79b573f9 We need to check archived accounts as well when creating the unaffected earnings account, to avoid triggering the validation if an archived account has the same code. This is failing on upgrades with `l10n_sa` installed where the account `sa_account_999999` has been archived.
This update resolves an issue where the VAT partner listing report was not displaying all relevant customers. The fix involves adjusting a setting within the report to load all partners, ensuring accurate reporting of financial data. This improves data visibility and reporting accuracy for tax compliance.
Original PR description
With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and…
With l10n_be company: - Create at least two invoices for two different customers (companies) for whom you will add a fake VAT number. Make sure the total on both your invoices is more than 250€ and set their Accounting date to last year. - Go check the VAT partner Listing report (Accounting > Reporting); make sure you see both partners in the listing. - Click on returns > Check that report return then Submit and download the XML file: both partners & amounts will appear. - Now with dev mode, go to Accounting reports, open the Partner VAT listing form > Options > set the "load more limit" to 1. Download the XML again: only the first partner appears (the only that was loaded with the load more limit. This commit is a backport of bugfix: PR odoo/enterprise#106134 commit e532750fe3dc1f2d10d995d01446b04a3a227a72 Original problem introduced in `saas-18.3`: PR odoo/enterprise#111783 commit 4c927b389252b595bcbb44d020899ae5abf0aa89 Ticket [link](https://www.odoo.com/odoo/project.task/6051120) opw-6051120
A test used in the payroll module (l10n_ch_hr_payroll_elm_transmission) was failing due to an incorrect date calculation. The fix involved adjusting the test's time setting to ensure accurate calculations for future payroll years, preventing a disruption in reporting.
Original PR description
[FIX] l10n_ch_hr_payroll_elm_transmission: fix avs test for faketime build
Bug reproduction:
1 - v.17->run test_generic_avs_deductions test with faketime 2027-01-01 12:00 UTC->test fails
Bug cause:
1 - In the test, compute_sheet()->_get_payslip_lines->_compute_rule->_get_avs_rates is called
2 - There is a line like that if line.date_from <= target and (not line.date_to or target <= line.date_to)
3 - I looked to avs_line_ids = fields.One2many(default=_get_default_avs_line_ids)
4 - In _get_default_avs_line_ids -> 'date_from': fields.Date.today().replace(month=1, day=1) date_from is calculated like that -> when the year is 2027, the date_from is 2027-01-01 and it is bigger than the target in the test.
Bug solution:
1 - I used @freeze_time("2026-02-28") in my test to prevent this behavior.
Runbot Error Link: https://runbot.odoo.com/odoo/runbot.build.error/240992
task - 6018940
Forward-Port-Of: odoo/enterprise#109975This update fixes a labeling issue with the 0% VAT rate for sales outside the EU in Sweden. The tax name has been corrected to '0% EX RS' to accurately reflect its usage, and the associated grid has been updated. This ensures accurate tax reporting and compliance for Swedish customers.
Original PR description
Currently, the tax for "VAT Sale of service outside EU 0%" has the 0% EU RS name and is associated with the se_39 grid. Since it is for outside the EU, it's name should be 0% EX RS and the grid should be se_40 opw-5798152 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251750
This update fixes an issue where Chrome logs weren't reliably captured during shutdown, particularly when errors occurred. The changes also address Chrome's log buffering behavior and add resilience to ensure a smoother shutdown process, preventing data loss.
Original PR description
odoo/odoo#255054 saved the chrome log at the end of a tour (logging that as `INFO` on success and `RUNBOT` on failure). However as it turns out there are a few issues with that: 1. In case of chrome error during termination (`stop`), those errors can not be in the log, since the log was already saved. 2. Chrome buffers logs a lot more than anticipated, and because `--v=0` logs are a lot less chatty than `--v=1` the logs routinely show essentially nothing (a few tour steps are logged then nothing). Also make `stop` a bit more resilient to chrome issues: - handle errors around ws shutdown - wait for chrome to shut down before we try to remove the data directory - also add a fallback *killing* chrome if it doesn't seem to be shutting down Forward-Port-Of: odoo/odoo#256306 Forward-Port-Of: odoo/odoo#256061
This update resolves an issue that prevented the creation of contracts when a working schedule had zero hours. The fix prevents a division-by-zero error during hourly wage computation, ensuring contracts can be created correctly. This improves the reliability of the Australian payroll module.
Original PR description
When a working schedule has 0 working hours, creating a contract raises a traceback during hourly wage computation. Steps to reproduce the error: - Install ``l10n_au_hr_payroll`` module - Switch to ``My Australian Company`` - Create a working schedule without any working hours - Create an employee and assign this working schedule > Save - Click on Contracts smart button Traceback: ```py ZeroDivisionError: float division by zero ``` https://github.com/odoo/enterprise/blob/bd746aa43f549c4f7813a849e00447b55e084f21/l10n_au_hr_payroll/models/hr_contract.py#L113-L115 The hourly wage is computed using the working schedule’s hours per day. When this value is 0, it results in the above traceback. sentry-7355577930 Forward-Port-Of: odoo/enterprise#111629
This update fixes an issue where URLs in emails were incorrectly encoded, potentially leading to display problems. The change utilizes modern URL handling techniques for accurate URL construction and display, ensuring correct links are presented to users. This improves the reliability of email communications within Odoo.
Original PR description
Before this commit, the URL was fully encoded using encodeUrl. This commit replaces this approach with the more modern [URL api](https://developer.mozilla.org/en-US/docs/Web/API/URL), which [handles encoding](https://url.spec.whatwg.org/#dom-url-href) properly. This commit also removes decodeUrl. It was possible for a user to send a URL and have a different one displayed in the UI due to decoding. Task-6041689 Forward-Port-Of: odoo/odoo#254383
A test tour was failing because the test user lacked the necessary security group (`group_production_lot`) to enable line grouping in the stock barcode model. This fix adds the required group, allowing the tour to complete successfully and ensuring proper functionality for lot scanning and packaging.
Original PR description
```js ---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour → Step .o_barcode_line_summary ---------- { 'trigger': '.o_barcode_line_summary', 'run': 'click' },…
```js
---------- FAILED: [7/19] Tour test_quality_check_packages_lots_tour →
Step .o_barcode_line_summary ----------
{
'trigger': '.o_barcode_line_summary',
'run': 'click'
},
------------------------------------------------------------------------
```
The tour `test_quality_check_packages_lots_tour` was failing at the step
waiting for `.o_barcode_line_summary` after calling `o_put_in_pack`.
**Root cause:**
the JS barcode model sets `groupingLinesEnabled` directly from
the `group_production_lot` security group flag returned by the backend:
https://github.com/odoo/enterprise/blob/bd35e9c16a6c0fd743c934024db2821b8ae21fdc/stock_barcode/static/src/models/barcode_model.js#L53
When `groupingLinesEnabled` is false, `groupLines()` skips the grouping
logic entirely and individual move lines are rendered as flat
`LineComponent` instances. The `.o_barcode_line_summary` element only
exists inside `GroupedLineComponent`, which is only rendered when lines
are actually grouped (i.e. a parent line has `line.lines` sublines).
The test setup already granted `group_tracking_lot` (required to show the
`o_put_in_pack` button) but was missing `group_production_lot`. Without
it, after scanning `lot-01` twice and packing, the two lot sub-lines were
never merged into a `GroupedLineComponent`, so `.o_barcode_line_summary`
never appeared in the DOM and the tour timed out.
Fix: add `group_production_lot` alongside `group_tracking_lot` in the
test user's groups so that line grouping is enabled in the JS model,
allowing `GroupedLineComponent` to render `.o_barcode_line_summary` as
expected by the tour.
similar fix - https://github.com/odoo/enterprise/pull/82677/changes/05883b2c9cadb1187df404a4bef638f933922755
---
runbot error:241926This update resolves a bug that prevented the FSM reporting tour from completing correctly when run without demo data. A new worksheet was added to stop the "Explore Worksheets" wizard from appearing, ensuring the tour flows as intended. This improves the user experience for accessing the FSM reporting features.
Original PR description
**Reason for creating the worksheet:** ------------- When the tour runs without demo data, only one worksheet exists, so the **“Explore Worksheets Using an Example Template”** wizard opens and stops the tour. To avoid this, I created an extra worksheet so the wizard does not open and the tour continues normally. https://github.com/odoo/enterprise/blob/85bd9d80a1a784f1baff1493b2eaec4a17ea9c9b/industry_fsm_report/models/project_task.py#L122-L135 task-4489657 Forward-Port-Of: odoo/enterprise#81823
This update clarifies the error message displayed when an upsell's start date is set after the next invoice date. This change ensures users receive clearer guidance, preventing confusion and potential issues with subscription billing. It’s a simple fix to improve user experience.
Original PR description
Update the error message when an upsell start date is on or after the next invoice date, so it be more clear for the users. task-5893032 Forward-Port-Of: odoo/enterprise#106757
This update corrects a change in the URL required to send e-invoices to the Serbian government. The previous URL was outdated, preventing proper e-invoice submission. This fix ensures compliance with Serbian regulations and allows seamless e-invoice processing.
Original PR description
**PROBLEM** The url to send e-invoice to the serbian government has changed. opw-6055622 Forward-Port-Of: odoo/odoo#256095
This update resolves an issue where Odoo displayed a misleading warning message to users when they didn't immediately set a password during file uploads. The system now correctly checks for a password during the saving process, improving the user experience and eliminating this unnecessary notification.
Original PR description
Before the change, when the user uploads a file, Odoo automatically shown a warning message saying that the content of the file or the password are incorrect. Now the system does not show the warning when a password is not set and checks if the password is set when saving task-6036219 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253834
This update corrects a technical detail by removing outdated tags (<report> and <act_window>) from the Odoo import files. These tags were previously removed in another change, but this commit ensures they are no longer present, maintaining the integrity of the import process. This ensures consistent and reliable data imports.
Original PR description
`<report>` and `<act_window>` tags has been removed in https://github.com/odoo/odoo/pull/98138, but not in the import_xml.rng file. This commit removes the two tags from the file. Forward-Port-Of: odoo/odoo#220116