Thursday, March 19, 2026
15 changes · saas-18.3
Resolved issues and error corrections
This update corrects a technical issue that prevented multiple expenses linked to a single payment from being correctly processed. The fix ensures that the system handles multiple expenses associated with a payment action smoothly, addressing a potential problem that arose during previous upgrades. This improves the reliability of expense tracking.
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#254167This update corrects a technical detail in the Account Avatax module, ensuring it correctly 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 effectively 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 a bug where subscriptions were incorrectly reopened after a credit note payment. The fix prevents the system from reopening subscriptions when a payment is made on a refund invoice, ensuring subscriptions remain in the correct churned state. This improves subscription management accuracy.
Original PR description
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and…
Steps to reproduce: ------------------------------ 1. Install Subscription module 2. Create a new subscription and confirm it 3. Create an invoice from the subscription. * Register a payment and ensure the invoice is in the Paid state. 4. Go back to the subscription and close it with any reason 5. Open the related invoice. * Create and Confirm Credit Note. * Register a payment for the credit note. 6. Go back to subscription Observation: ------------------------------ The subscription is automatically set back to `In Progress` even though it was previously churned. Issue: ------------------------------ The method `_reopen_paid_churned_subscription` reopens churned subscriptions when an invoice is set to `in_payment` or `paid`. There was no check to exclude refund moves (`move_type = 'out_refund'`), causing the subscription to be reopened when a credit note is paid. Solution: ------------------------------ Add a condition to exclude refund invoices from the reopening logic opw-5947999 Forward-Port-Of: odoo/enterprise#108487
This update corrects a technical error in how images are displayed within Odoo reports. Specifically, a problem with the way image URLs were handled has been resolved, ensuring images are now correctly rendered. This improves the overall visual quality and reliability of reports.
Original PR description
Forward-Port-Of: odoo/odoo#254633
This update resolves a problem where header border widths were incorrectly set to full widths due to an input field accepting multiple values. The change ensures consistent border widths for standard headers while still allowing full borders for specific header templates. This improves the visual consistency of website headers.
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
This update fixes a bug that prevented users from creating backorders when using batch transfers with specific picking configurations. The issue stemmed from an 'incompatible types' error during batch validation. Now, users can successfully create backorders without encountering this error, ensuring smoother batch transfer workflows.
Original PR description
Scenario: - Create two pickings with same partner with at least two moves each, the picking type should have auto_group and auto_confirm - Add to a batch transfer - Change the quantity on a move line, unlink the other - Validate the batch ### Before this PR - Clicking "create backorder" the "incompatible types" error appear because tries to assign the batch currently validating to the backorder picking ### After this PR - No error appear --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#251952
This update resolves an issue preventing Odoo from correctly generating UBL invoices for Hungarian businesses. The problem stemmed from a requirement that VAT numbers always start with a country code, which is not standard practice in Hungary. The fix automatically builds the VAT number from the Hungarian Tax Number, ensuring invoices meet regulatory requirements and can be successfully sent to the NAV.
Original PR description
Problem --------- When building the UBL, invoices with Hungarian partners get hit with the following constains: "The VAT of the [role] should be prefixed by the country code". However, Hungary allows for VAT numbers that do no start with the country code. Every Hungarian business is assigned a Tax Number (Adószám) that follows a fixed 11-digit format: NNNNNNNN-Y-CC. Solution --------- Build the VAT number from the Domestic Tax Number if it is not the case. no-task --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#253663
This update prevents the forum from freezing if it takes too long to retrieve information. By adding a timeout to the requests, the forum now responds more reliably, improving the user experience and preventing potential downtime. This is a routine maintenance fix.
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 update fixes an issue where stock move lines were incorrectly assigning destination packages, particularly for reusable packaging. The change ensures that destination package assignments are only applied to disposable packaging, streamlining the process for both full packs and individual deliveries. This improves the accuracy of stock tracking.
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
This update ensures that when importing tasks from spreadsheets into Field Service, the recurrence settings specified in the spreadsheet are correctly applied, rather than defaulting to standard recurrence values. Previously, importing tasks without a recurrence ID would overwrite these settings. This change improves data accuracy and consistency for task scheduling.
Original PR description
### Steps to reproduce: - Create a xlsx sheet with some fsm_tasks values with recurrence values - Import the sheet to Field Service > Tasks - Navigate to the created tasks - Notice the recurrence values is the default ones not the ones in the imported sheet ### Cause: If we are importing records without recurrence_id value we will set the recurrence fields' values to the default values while we might already have values for those fields ### Fix: Check if we have values for recurrence fields we don't set the defaults and let the create method create the project.task.recurrence record and set the recurrence_id opw-5925546 Forward-Port-Of: odoo/odoo#249104
This update addresses a visual issue where blank space appeared in activity cards after a description was cleared. The fix ensures that the activity note is only displayed when there's actual content, resulting in a cleaner and more professional user interface. This improves the overall user experience.
Original PR description
**Description of the issue/feature this PR addresses:** When an activity description is cleared, the stored value may still contain empty HTML content. The UI was still rendering this as a note,…
**Description of the issue/feature this PR addresses:** When an activity description is cleared, the stored value may still contain empty HTML content. The UI was still rendering this as a note, resulting in unnecessary blank space in the activity card. **Current behavior before PR:** Even when the activity description is cleared and contains only empty HTML, the activity note container is still rendered, leaving visible empty space in the UI. **Desired behavior after PR is merged:** The activity note is rendered only when it contains meaningful content. Empty HTML descriptions are ignored, preventing blank space from appearing in the activity card UI. Before <img width="445" height="84" alt="image" src="https://github.com/user-attachments/assets/f6648bb0-78d9-4063-a347-fe664370106e" /> After <img width="459" height="72" alt="image" src="https://github.com/user-attachments/assets/84c2063a-7c68-4dfe-b729-566ca4b5dcd1" /> task-[4752613](https://www.odoo.com/odoo/project/1519/tasks/4752613) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#252139
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 consistently 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 users with limited accounting access couldn't successfully import vendor bills via XML. The fix involves a change in how Odoo assigns data to ensure restricted users receive appropriate error messages when attempting to import, preventing unexpected behavior. This improves data integrity and security.
Original PR description
[FIX] account_edi_ubl_cii: restricted access user cannot import bill To reproduce: - create a user that has readonly access in Accounting - try to import a XML in vendor bills -> should traceback This commit modifies the `res_field` assignation by setting both `res_model` and `res_id` at the same time Forward-Port-Of: odoo/odoo#254698
This update resolves a technical issue that could cause errors when importing bank statements with multiple journals using different currencies. The fix prevents a redundant function call, streamlining the process and ensuring accurate data import for our international customers.
Original PR description
When having multiple journals with the same IBAN, but different currencies, we could have a singleton error if they are not all configured the same (besides the currency). This happens in the cron that fetches new CODAs as we first fetch all CODAs. Then, for each, we have to dispatch it in the right journal. To do so, we rely on `_parse_bank_statement_file` which is called on `self`, which itself calls `_get_coda_final_statements` that triggers the singleton error. However, at this point, we don't care about calling `_get_coda_final_statements` since we only want to retrieve the IBAN and the currency of the CODA, we don't care about the other details. Thus, the solution here is to ignore this call if we don't need it while just retrieveing the necessary info to match a journal before even creating the statements. opw-5723017 opw-6036909 Forward-Port-Of: odoo/enterprise#111101
This update corrects a technical issue that caused the Odoo Enterprise system to crash when resetting purchase data fetching settings. The fix ensures that the system correctly retrieves purchase data, preventing future errors and maintaining data integrity. This resolves a problem impacting the reliable operation of the KE-EDI OSCO module.
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