Thursday, March 19, 2026
22 changes · saas-18.4
Resolved issues and error corrections
This update corrects how image URLs are handled when pages or reports are generated. It helps prevent incorrectly formatted image links, improving reliability for content that displays images.
Original PR description
Forward-Port-Of: odoo/odoo#254633
This fixes an issue where opening expenses from a payment could fail after an upgrade if that payment was linked to more than one expense. Users can now access all related expenses without encountering an error.
Original PR description
**Description:** In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple expenses. When opening expenses from the payment action,…
**Description:**
In previous versions, a single move could have multiple payments linked to it, and that move could also be linked to multiple
expenses. When opening expenses from the payment action, which caused a singleton error when multiple expenses were linked.
This situation can occur during upgrades because older versions https://github.com/odoo/upgrade/pull/9685/changes here is identified allowed creating such records. However, after the removal of expense reports [^1], this type of record can no longer be created in newer versions.
**To fix the issue**
the code now handles multiple expenses instead of assuming a singleton.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2283, in _serve_db
return service_model.retrying(serve_func, env=self.env)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 185, in retrying
result = func()
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2338, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2553, in dispatch
result = self.request.registry['ir.http']._dispatch(endpoint)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_http.py", line 355, in _dispatch
result = endpoint(**request.params)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 794, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 38, in call_button
action = call_kw(request.env[model], method, args, kwargs)
File "/home/odoo/src/odoo/19.0/odoo/service/model.py", line 94, in call_kw
result = method(recs, *args, **kwargs)
File "/home/odoo/src/odoo/19.0/addons/hr_expense/models/account_payment.py", line 37, in action_open_expense
'name': self.expense_ids.name,
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 5940, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: hr.expense(22, 21)
```
opw-5494047
upg-3974547
[^1]: https://github.com/odoo/odoo/pull/189701
Forward-Port-Of: odoo/odoo#254167A test for German accounting was failing because a newly created test user did not have the required accounting permissions to create journal entries. This update assigns the needed permission during test setup, improving reliability without changing normal business workflows.
Original PR description
The crash occurs due to the test case introduced in PR #246920. While creating the user, no accounting group was assigned, so when this user attempts to create a Journal Entry, an AccessError is raised. **Root cause:** - In the previous version, when a public user was created, the required groups for creating an account move were assigned by default. However, in the current version, only a single group is assigned by default, which is Role/Member. As a result, when attempting to create an account move, an access error. In this commit, the required accounting group is added during user creation to ensure the test runs correctly. Runbot-241930 Forward-Port-Of: odoo/odoo#254360
Fixes an issue where validating a delivery linked to a confirmed sales order with no order lines could fail. The system now uses a safe default ordering value when adding the needed sales order line, allowing the delivery to be completed normally.
Original PR description
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and…
Currently, an error occurs when user validates a picking. **Steps to Reproduce:** - Install the `sale_management` and `sale_stock` modules. - Create a `sale order` without `any sale order lines` and `confirm` it. - Go to `Inventory > Operations > Deliveries` and create a `picking record by adding a move line` with a `quantity` greater than `zero`. - In the `Additional tab`, select the `sale order (the one without order lines)`. - Now `validate` this delivery. **Error:** `ValueError: max() arg is an empty sequence` This error occurs because, during validation of the delivery record, the system attempts to `create a sale order line` for the product. If the sale order does not have any `existing order lines`, the system tries to determine the `sequence` from existing sale order lines. Since `no lines exist`, the `sequence list is empty` [1], raising the error. This commit ensures that when a sale order has no existing order lines, a default sequence value of zero is used. [1]- https://github.com/odoo/odoo/blob/9e404b52e8c9375a6534a67cfb0fcc0df523402b/addons/sale_stock/models/stock.py#L164 sentry-7089149997 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253933 Forward-Port-Of: odoo/odoo#239030
The website editor now treats standard header border width as a single value, preventing accidental full borders when multiple numbers are entered. Header designs that intentionally need full borders still support multiple border values, preserving those templates while avoiding unexpected visual changes.
Original PR description
Previously, the border width input for headers allowed multiple values. This was required for specific header templates (e.g. rounded box) that use a full border. However, most headers only apply a border on the bottom. When the input had multiple values, the scss would break, resulting in full border. This change ensures that, for headers without the .o_full_border class, only the first value of the saved border width is used. As a result, the input behaves like a single-value field (similar to font size inputs) for standard headers, while still supporting multiple values for templates that require a full border. Steps to reproduce the issue: - Go to Edit mode - Click on the Header - In the Border option, enter "1 2" and leave the input to validate => The input display "3" and the header has a full border. task-5500516 Forward-Port-Of: odoo/odoo#254483 Forward-Port-Of: odoo/odoo#244415
The forum now limits how long it waits when fetching page titles for shared links. This prevents a slow or unresponsive external website from tying up the forum feature and helps keep the site responsive.
Original PR description
Add a timeout to the requests done by /forum/get_url_title to avoid blocking indefinitely Forward-Port-Of: odoo/odoo#254607
This fix prevents reusable packages from being incorrectly marked as the destination package during deliveries. It helps keep package tracking accurate by applying destination package behavior only where it is appropriate for disposable packaging.
Original PR description
Commit https://github.com/odoo/odoo/commit/0358963e2088a309141f092fbe8f7a98786cc1d8 forces the `result_package_id` on the package level stock move lines (meaning move lines being part of entire package move) to be the source package. This makes sense when moving entire packs but not in case of delivery with disposable packages. We remove the line that set the destination package for any package type and keep the one doing this for disposable package only. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253323
When an Italian Public Administration customer refuses an electronic invoice, Odoo now displays the refusal reason in the invoice header. This helps users quickly understand why the invoice was rejected without needing to inspect the underlying XML message.
Original PR description
When a Public Administrator business refuses an invoice, they also give a reason message (EsitoCommittente/Descrizione), which comes through the IAP to Odoo as an XML tag aside the Outcome code (EsitoCommittente/Esito). Before this PR, the message was ignored, now we show it in the invoice's header. ref: https://www.fatturapa.gov.it/export/documenti/messaggi/v1.1/MessaggiTypes_v1.1.xsd <img width="823" height="232" alt="image" src="https://github.com/user-attachments/assets/8f222f6b-1615-4dd2-a5dd-25e0991ea037" /> <img width="942" height="206" alt="image" src="https://github.com/user-attachments/assets/cdf109ff-40d0-4c50-bdc7-51fb4ea15c98" /> Ticket [link](https://www.odoo.com/odoo/project.task/6041276) opw-6041276 Forward-Port-Of: odoo/odoo#254481
Fixes an issue where resetting the "Lead Forward: Send to partner" email template caused a validation error. This helps administrators safely restore the default template without interrupting lead forwarding workflows.
Original PR description
Steps to reproduce: - Create a lead > click on gear icon > Forward to partner - Send the forward and ensure there is at least one record of crm.forward.to.partner - Navigate to email templates technical settings menu and search for Lead Forward: Send to partner - Click on Reset Template in the template form Current behavior: - Validation Error thrown Expected behavior: - No validation error thrown and template is reset Note: MailTemplate._check_can_be_rendered was added in version 18.3 which checks for invalid object references when trying to alter + save templates. This template was out of date and fails the check Referenced PR: https://github.com/odoo/odoo/pull/176623 opw-6001560 Forward-Port-Of: odoo/odoo#252599
Report headers now use a smaller logo size so the address area has room for one additional line. This prevents address details from being cramped or cut off in bubble-style report layouts, improving printed and PDF document readability.
Original PR description
The bubble layout was changed in commit[1] but the logo size is too big to accomodate a sufficient amount of address lines. task-5951770 [1]: odoo/odoo@8eb61a245cd3b650e309fdb55d24654c34d785cd Enterprise PR: https://github.com/odoo/enterprise/pull/110858 | Before | After | |--------|--------| | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/bb2671c3-62c8-45df-8039-4a9455d21982" /> | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/d36ca5fe-24b3-4a74-8323-2c587d11495e" />| | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/2b1c7ce9-2d14-47ab-9fc0-b4bca33e412f" /> | <img width="566" height="182" alt="image" src="https://github.com/user-attachments/assets/df189280-b274-4dea-9ec1-9482c47b00e5" /> | --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The change makes automated website sales checks wait until the correct page is fully ready before continuing. This reduces false test failures caused by timing issues in newer Chrome versions, improving confidence in release validation without changing customer-facing behavior.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/odoo#254461 Forward-Port-Of: odoo/odoo#253896
This update corrects a technical detail in the Account Avatax module, ensuring it properly identifies the company it's associated with. Previously, a key setting was missing, which has now been added to improve data accuracy and functionality. This ensures Account Avatax operates correctly within the Odoo Enterprise system.
Original PR description
Since the beginning `account_avatax` has had all of it's data stored on the company, however, it missed the company_dependent key in settings to mark it as such. This commit fixes that. Followup of odoo/odoo#254242 task-none Forward-Port-Of: odoo/enterprise#110983
This update resolves an issue where links within Helpdesk email templates were incorrectly identified as links instead of buttons. The change ensures buttons function as intended, allowing users to properly interact with ticket information. This improves the overall usability of the Helpdesk system.
Original PR description
Without the `btn` class, buttons are identified as links by the editor. This commit adjusts the buttons inside the mail templates so that they are properly handled by the editor. Steps to reproduce: - Have demo data - Turn on developer mode - Go to Helpdesk > Customer Care - Open ticket "Where can I download a catalog?" - In the debug menu, go to Messages - Open the first template - Click on the "View Ticket" button - Edit the link => The link popover recognized it as a link instead of a button. As of saas-18.2, the style is replaced by a plain link style when changing the URL. task-5948539 Forward-Port-Of: odoo/enterprise#110797 Forward-Port-Of: odoo/enterprise#107888
This update corrects a bug that caused incorrect decimal values to be generated in intrastat XML reports for French companies. The issue stemmed from how the system processed invoice data, specifically when handling weights with decimal amounts. This fix ensures accurate reporting for international trade data.
Original PR description
Steps to reproduce: - Select a French company and activate intrastat - Create an invoice with a 100% discount to a european partner and provide intrastat values such as intrastat code, product commodity code, ... and most importantly a weight with a decimal amount. - Create at least one other invoice to a european partner that has a date earlier than the first one (but on the same month) - Go to intrastat report and export the XML (DEBWEB2) and select EMEBI and then Departures. -> Issue: The line that got processed after the one with a 0 value is not properly post-process regarding the integer conversion because we used to iterate on a list that was modified at the same time. opw-5973832 Forward-Port-Of: odoo/enterprise#110971
This update resolves an issue where GS1 barcode filtering would fail due to an incorrect interpretation of certain barcodes as dates. The fix prevents errors from blocking product filtering, ensuring internal transfers and barcode scans function correctly. This improves the reliability of our inventory management system.
Original PR description
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal…
Steps to reproduce: - Activate the GS1 nomenclature - Create a product "P1" with the barcode: 15099590225865 - Create an internal transfer with one unit of P1 - Go to Barcode > Operations > Internal Transfers - Scan the barcode: 15099590225865 to filter transfers by this product barcode Problem: An validation error is raised: A ValidationError is raised: "A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date." Explanation: GS1 barcodes must follow a strict nomenclature based on well-defined rules. For example, a GS1 product barcode should start with the Application Identifier 01 followed by 14 digits. The GS1 parser processes the barcode rule by rule and applies the first matching rule. In this case, the barcode 15099590483921 is interpreted as a date because it starts with "15", which corresponds to a GS1 Application Identifier for a date. As a result, the parser attempts to convert the first six digits into a date and raises a ValidationError. Solution: Catch the ValidationError raised during GS1 date parsing in filter_on_barcode and explicitly reset parsed_results to False, allowing the normal filter on product resolution logic to continue. This prevents GS1 parsing errors from blocking valid barcodes and ensures that product is correctly filtered opw-5929064 Forward-Port-Of: odoo/enterprise#110679 Forward-Port-Of: odoo/enterprise#110636
This update resolves a timing issue that was causing delays in the website's onboarding tours, particularly related to translation loading. The fix ensures that translation requests are handled promptly, preventing interruptions and improving the user experience. This was triggered by recent changes in Chrome versions.
Original PR description
This commit adds an intermediary step ensuring the proper page has been reached before actually doing the checks and avoiding to let startup requests (like the loading of the translations) pending at the end of the tour (and the eventual stop of the runner browser). Note: this is most likely due to a timing (indeterministic by nature) change, emphasised by recent Chrome versions (like v145). runbot-239128 Forward-Port-Of: odoo/enterprise#111013 Forward-Port-Of: odoo/enterprise#110648
This update corrects a calculation issue related to employee appraisal dates. The fix ensures appraisal dates are accurately determined based on company settings like recruitment duration and appraisal schedules. This improves the reliability of appraisal workflows within the system.
Original PR description
Issue: The computation of the next appraisal date for employees depends on setting the appraisal plan for a company or changing the company's settings for `duration_after_recruitment`, `duration_first_appraisal`, `duration_next_appraisal`. Fix: Moving the test employee creation after configuration of the company settings for the appraisal plan. task-6050719
This update resolves a visual issue where the map view in the "My Dashboard" sometimes collapsed. The fix removes conflicting height settings and adds a minimum height to the map, ensuring it always displays correctly regardless of the number of records shown.
Original PR description
This commit fixes rendering height issues when the map view is displayed inside "My Dashboard". * Removed `height: 100%` from the map and pin list containers. This conflicting rule interfered with the flexbox layout, often causing the map to collapse entirely since it couldn't compute its own height. * Added a `min-height` to the map renderer. This ensures the map always occupies a reasonable amount of space in the dashboard, even when there are few or no records to display. task-6022958 Forward-Port-Of: odoo/enterprise#110968 Forward-Port-Of: odoo/enterprise#110790
This update resolves an issue where long tax amounts on invoices were causing display problems. The fix ensures that tax totals are correctly rendered, regardless of the number of digits, improving invoice clarity for users in the Keňa (Kenya) edition of Odoo Enterprise. This enhancement ensures accurate reporting and a better user experience.
Original PR description
This commit aims to: Fix Display issue when the amount is long. task-5162891 Forward-Port-Of: odoo/enterprise#110649 Forward-Port-Of: odoo/enterprise#100319
This update corrects a sizing problem with the company logo across various Odoo reports. The previous CSS selector was too broad, affecting multiple reports and causing the logo to appear oversized. This change ensures the logo displays correctly and consistently in all reports.
Original PR description
This selector is generic and is impacting all the reports in `report_templates.xml` which are making use of the same class name. task-5951770 Community PR: https://github.com/odoo/odoo/pull/249432
This update resolves an issue where tests were incorrectly deleting taxes in reports related to the Indian Goods and Services Tax (GST). The change now properly removes taxes from the account move line, ensuring accurate reporting calculations and aligning with current tax regulations. This improves the reliability of the GSTR reports.
Original PR description
Before this PR: - A test case was deleting taxes. After this PR: - Removed the taxes from the account move line instead of deleting the taxes. Related PR: https://github.com/odoo/odoo/pull/245243 task-5472834 Forward-Port-Of: odoo/enterprise#105174
This update corrects a technical error that caused the Odoo Enterprise system to crash when resetting purchase data fetching settings for a company. The fix ensures that the system correctly retrieves purchase data, preventing future disruptions and maintaining accurate records. This resolves a previous issue impacting data reliability.
Original PR description
In case the purchase last fetch data is resetted to `False` on the company, the next cron run will crash with: `type object 'datetime.datetime' has no attribute 'datetime'` This commit fix the wrong default date fallback. opw-5220129 Forward-Port-Of: odoo/enterprise#111124