Thursday, February 26, 2026
25 changes · saas-18.3
Resolved issues and error corrections
This fix addresses a technical issue where a syntax error during UI view rendering could cause an UnboundLocalError. The update ensures that a 'None' value is assigned before attempting to suppress the error, preventing the crash. This improves the stability of the user interface.
Original PR description
When syntax error will raise ``node`` will not assign. So, assign ``None`` before error will surpess. Note:- found it during testing. ``` Traceback (most recent call last): File…
When syntax error will raise ``node`` will not assign. So, assign ``None`` before error will surpess.
Note:- found it during testing.
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2273, 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 2328, in _serve_ir_http
response = self.dispatcher.dispatch(rule.endpoint, args)
File "/home/odoo/src/odoo/19.0/odoo/http.py", line 2543, 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 788, in route_wrapper
result = endpoint(self, *args, **params_ok)
File "/home/odoo/src/odoo/19.0/addons/web/controllers/dataset.py", line 32, in call_kw
return 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/web/models/models.py", line 113, in web_read
values_list: list[dict] = self.read(fields_to_read, load=None)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3490, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3747, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 6686, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1746, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 1917, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 4952, in _compute_field_value
determine(field.compute, self)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 81, in determine
return needle(*args)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 366, in _compute_invalid_locators
if invalid_locator := assess_locator(source, spec):
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 330, in assess_locator
if node is None:
UnboundLocalError: local variable 'node' referenced before assignment
```
opw-5956964
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update introduces a simpler command-line option for running Odoo tests. Previously, users needed to specify test tags directly. Now, a single alias `--test-tags` is used, streamlining the testing process and making it easier for developers to execute tests. This change improves the efficiency of our testing workflow.
Original PR description
Backport of https://github.com/odoo/odoo/pull/234287 <img width="408" height="151" alt="image" src="https://github.com/user-attachments/assets/7f22826f-6887-432b-8baf-8a6778b9cadf" /> Forward-Port-Of: odoo/odoo#249854 Forward-Port-Of: odoo/odoo#249123
This change resolves a test failure in the stock module caused by demo data interfering with the search functionality. The update creates new data and avoids conflicts with existing demo data to ensure the test runs reliably.
Original PR description
The `test_lot_search_partner_ids` expects a specific number of lots/SNs to exist in the database in order to ensure its custom `partner_ids` search works correctly. Because of this, the test fails if any lot demo data is installed. Therefore we create all new locations, products, lots and add extra search domain fields to avoid loading any of these demo data. Also add in extra long partner name to avoid conflicts with overlapping demo/test partner names. runbot error: 162921 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where adding a column within a list item caused a system error. The fix separates column insertion within lists, preventing errors related to restoring selections on removed elements. This ensures smoother and more reliable column addition within list structures.
Original PR description
Problem: When trying to add a column under a list item, a traceback occurs. Cause: The list item is removed during the operation, but the selection that is restored still references the removed list item. As a result, the selection is restored on a disconnected element, causing a traceback. Solution: Handle column insertion inside lists separately. In this case, according to the specifications, we split the list and insert the columns between the resulting lists (or after the list if the cursor is in the last list item). This avoids restoring the selection on a removed node. Steps to reproduce: - Add any list. - Run `/column` while the cursor is inside a list item. - Observe the traceback. task-5916246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248206
This update addresses a critical maintenance task, ensuring our tax code data is current. The tax codes haven't been updated in four years, and this fix ensures continued accuracy for financial reporting. A future enhancement will allow users to initiate this update automatically.
Original PR description
It's been 4 years since the last update [1]. No codes were removed. At some point it would be nice to add this to the avatax_sync_company_params() method so it can be initiated by the user. But we need to update this file regardless, and the mechanism would need to be smart enough to not cause duplicates when e.g. the user has synced it themselves, we then update the csv and they then update the module. [1] https://github.com/odoo/enterprise/pull/30220 opw-5928245 Forward-Port-Of: odoo/enterprise#108209
A recent update removed a warning that appeared when users attempted to cancel paid or posted point-of-sale orders. This was due to a change in how the system handles order updates. This fix restores the warning, ensuring users are alerted before finalizing a paid order, preventing potential errors.
Original PR description
From 18.2, the warning to prevent users to cancel paid or posted orders from backend was no longer displayed. It's caused because it was handled in the write() method from pos.order model. But, since a recent change, we call write() method only on draft orders. So, if there is no draft orders selected, the warning doesn't appear. task: 5959917 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#250074
This update fixes an issue where back-in-stock notifications were sent using the wrong email address. Now, notifications will use the email address of the website where the customer placed their request, ensuring customers receive accurate and timely updates. This change aligns with the latest Odoo version and improves the customer experience.
Original PR description
…notification # The problem The mail sent to notify a customer that a product is back in stock used the e-mail of the company associated with the product. We would rather use the e-mail of the company associated with the website the notification request was done in. This commit aligns versions 18.0+ with what is done on master (https://github.com/odoo/odoo/commit/8ec57b1115a55e8b59db9b8c1e843c6a1c888db3) opw-5868889 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#249299
This update fixes an issue where warehouse names with only numbers (e.g., '01') were displayed incorrectly in the barcode app. The fix removes a browser setting that caused numerical warehouse codes to be reversed, ensuring they are always shown in the correct order. This improves the user experience when scanning products.
Original PR description
### Steps to detect the bug: - Download stock apps - Enable "storage locations" settings under warehouse index - Change name of warehouse with a name composed only of numbers (ex. 01) - Create a…
### Steps to detect the bug:
- Download stock apps
- Enable "storage locations" settings under warehouse index
- Change name of warehouse with a name composed only of numbers (ex. 01)
- Create a product (with barcode number)
- Insert a number of products available with smart button "on hand"
- Create a new delivery for that product
- Go to barcode app and search for the delivery you just created
- Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.
### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
opw-5730199
Forward-Port-Of: odoo/enterprise#107920This update removes unnecessary HTML wrapping from article content. Previously, a 'div' tag was added to ensure proper parsing of article bodies, but this caused an increase in HTML depth. This change improves the efficiency and cleanliness of article formatting, preventing potential issues with repeated usage.
Original PR description
Prior to this commit, `_get_transformed_body_from` wrapped the source body in a `div` because `lxml.html.fragment_fromstring` is used with a `create_parent=True` argument. That argument is required because otherwise, the function throws an error if there are multiple root nodes in the parsed string, which is frequent in an article body. The final returned string still contained that additional `div` ancestor. This does not break an article per se, but repeated usage would increase the html structure depth by 1 every time, and that additional `div` was not part of the function desired transformations. task-5960616 Forward-Port-Of: odoo/enterprise#108310
Some libraries expect to find the language direction on the HTML element (e.g. Bootstrap). As we didn't set it, there were some issues. For instance on the website: - set the website language to some RTL language (e.g. Arabic) - drop an image gallery snippet and save - navigate with the keyboard to the carousel and start using the arrows to switch images => Pressing left should show the _next_ image, and pressing right should show the _previous_ image (contrary to LTR languages). This is ill
Original PR description
Some libraries expect to find the language direction on the HTML element (e.g. Bootstrap). As we didn't set it, there were some issues. For instance on the website: - set the website language to some RTL language (e.g. Arabic) - drop an image gallery snippet and save - navigate with the keyboard to the carousel and start using the arrows to switch images => Pressing left should show the _next_ image, and pressing right should show the _previous_ image (contrary to LTR languages). This is illustrated by the image indicators at the bottom of the carousel (the 1st image is on the right, the last image on the left). But without `dir="rtl"` on the HTML element, the arrows keep their LTR behavior: pressing left goes to the previous image, and right to the next image. task-5109547 Forward-Port-Of: odoo/odoo#250257 Forward-Port-Of: odoo/odoo#240611
This update resolves an issue preventing the SAF-T report from correctly identifying suppliers for fixed assets. The fix ensures that the report accurately pulls supplier data by incorporating depreciation lines alongside journal entries, addressing a discrepancy caused by bills being posted in a previous period.
Original PR description
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets"…
**Steps to reproduce:** - Install l10n_ro_saft - Switch to a Romanian company (e.g. RO Company) - Create an asset model: * Method: Straight Line * Duration: 12 Months - Configure a "Fixed Assets" account: * Automate Asset: Create and validate * Asset Model: [the asset model created above] - Create a bill: * Vendor: [create a new vendor] * Bill Date: [last month] * Invoice Line: [A line with the fixed asset account] - Confirm the bill - Go to "Accounting / Reporting / Audit Reports / General Ledger" - Select the current month (The fixed asset account should be present) - In the cog menu, select "SAF-T (D406 Asset Declaration)" **Issue:** A traceback is raised while trying to display the name of a supplier. **Cause:** To display the supplier name of an asset, a dict having the id of the customer or supplier as key (i.e. partner_detail_map) is used. This dict is build by getting the list of all partners linked to a posted journal item on an asset (or liability) account in the period of the report. In this case, it's the current month. However, the created bill has been posted the month before. So no journal item is found for the vendor that has been created just for the bill and therefore there is no key for him in the dict, which leads to the error when trying to get the id of the supplier of the asset in the dict. **Solution:** Instead of just fetching the posted entries linked to a receivable or payable account in order to get the list of the potential customers and suppliers, we also fetch the depreciation lines that are linked to an asset account and can still be in draft. opw-5499918 Forward-Port-Of: odoo/enterprise#105987
This update streamlines the process of finding and creating bank accounts within Odoo Enterprise. The changes consolidate logic, ensuring more consistent and reliable bank account management across several key modules. This improves data accuracy and simplifies the setup of financial transactions.
Original PR description
*: account_invoice_extract,hr_constract_salary,payment_sepa_direct_debit Forward-Port-Of: odoo/enterprise#108238
This update corrects a display issue where product attributes with a single custom value were incorrectly shown in product specifications and single-value lists on the website. The fix ensures that these attributes are only displayed in the main product attribute section, improving the user experience and data consistency. This resolves a visual inconsistency impacting product presentation.
Original PR description
### Issue: Due to this bug, an attribute with a single custom value will be shown in specifications and single value attributes. #### Steps to reproduce: 1- Create a product. Add a `Free text` attribute. 2- Navigate to product page on the website. 3- From website editor, style tab, switch `specification` style. 4- With specification style set to `None`, you can see this attribute in single value attributes list. 5- With other 2 styles you can see this attributes in specifications. Expected: In both steps 4 and 5, this attributes shouldn't be displayed there because it is already displayed in main attributes where you can set the value. Initially fix was to filter `ProductTemplateAttributeLine` in `_prepare_single_value_for_display`, however it would cause empty specification sections. To avoid that we also need to filter out single custom value attributes in `_prepare_categories_for_display`. opw-5484721 Forward-Port-Of: odoo/odoo#244234
A recent change was causing the 'Publish & Send' button to disappear in the scheduling interface. This fix removes a temporary workaround that was adding a context variable, restoring the button's visibility. This ensures users can correctly send their shift updates.
Original PR description
## Issue Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button. ## Cause The…
## Issue
Since commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2, `planning_test_tour_no_email` is failing when trying to click on the (missing) `Publish & Send` button.
## Cause
The commits adds the `my_planning_action` attribute to the context when opening the `Schedule by Resource`. This allowed to display the `I Take It!` button when opening an open shift, but it also removed the `Publish & Send` button, as its condition to be invisible consistently contains `context.get('my_planning_action')` [[1](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L11), [2](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L78-L79), [3](https://github.com/odoo/enterprise/blob/6892fbda8717effdf3eac06eb6783f1c238ce789/planning/views/planning_views.xml#L273-L274)].
## Fix
The objective is to fix the bug from previous commit https://github.com/odoo/enterprise/commit/a0f44c2bdb2 differently. Instead of adding the `my_planning_action` to the context, we remove the conditions on the `I Take It!` button.
runbot-241028
Forward-Port-Of: odoo/enterprise#108333This update fixes an issue in the Philippines check localization module where check amounts weren't accurately reflecting payments after withholding taxes. Now, check printing displays the net payment amount, ensuring correct financial reporting for Philippine businesses. A new test case has been added to verify this change.
Original PR description
In Philippines' check localization module, the amount on check should be based on the net amount after deducing withholding amount for payments if the payment is with taxes that are set as withholding on payment. This commit fixes the check print's values to reflect the net amount. Minimal test case is also added to safeguard the new behavior. [Task-5928813](https://www.odoo.com/odoo/all-tasks/5928813) Forward-Port-Of: odoo/enterprise#108611
This update fixes an issue where sales order statuses were displayed in an incorrect alphabetical order within the Kanban view. The change ensures that statuses like 'Cancelled', 'Quotation', 'Sale Order', and 'Quotation Sent' appear in the logical order expected by users. This improves the clarity and usability of the sales order management process.
Original PR description
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as…
Steps to produce: --- - Install sales module. - Open sales module > orders > switch to kanban view. - Then make it group by status. Observation: --- - The order of status is not proper. - It comes as Cancelled, Quatation, Sale order, Quatation sent. Root cause: --- - When we perform Group By > Status, the method `web_read_group()` is executed. then in chain `_web_read_group()` calls `read_group()` without providing any explicit `orderby`. Inside `read_group()`, if orderby is not provided, it sets the order to the grouped field itself. - Inside `_read_group()`, the SQL query constructed with an order by clause on the grouped field (state). Therefore, the values are retrieved in alphabetical order as `cancel, draft, sale, sent`. Solution: --- - Define `group_expand` on the `state` field. During `read_group()`, `_read_group_fill_results()` calls this method and reorders the groups accordingly. - This overrides the alphabetical SQL order returned by `_read_group()` and ensures the correct logical status order in Kanban view. opw-5497664 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#248776
This update ensures that opening notes are consistently saved to the system, regardless of whether the cash payment method is enabled. Previously, this data was lost when the cash method wasn't configured, leading to potential data inconsistencies. This change improves the reliability of POS note tracking for all users.
Original PR description
Before this commit: -------------- - When the cash method was not available for config, opening notes values were not being stored in session data. After this commit: -------------- - Opening notes values will be stored in session data even when the cash method is not available for config. task-5474822 Forward-Port-Of: odoo/odoo#249953 Forward-Port-Of: odoo/odoo#243956
A recent test in the payroll system was failing when the 'Attendance' module wasn't installed. This update moved the test to a separate module to ensure it consistently runs with the necessary components, improving overall payroll system reliability. This resolves a recurring issue impacting payroll processing.
Original PR description
Purpose: `test_05_fully_flexible_contracts_payslip` was failing without attendance installed as it creates contracts with `'work_entry_source': 'attendance'` Fix: moved the test to `hr_payroll_attendance` to ensure that it always runs with attendance installed pr introducing the test: https://github.com/odoo/enterprise/pull/93935 task-id: 5902805 Forward-Port-Of: odoo/enterprise#106320
This update resolves a minor performance issue in the website and web editor components related to how initial pages are loaded in Firefox 148. By using empty iframes, the system now completes page loading synchronously, eliminating a delay previously caused by Firefox's update. This ensures a smoother user experience.
Original PR description
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing…
Firefox 148 fixed the behavior of `about:blank` documents, as explained in their [release notes]: > The initial about:blank document is now Web-compatible. If the first > navigation of a browsing context goes to about:blank, it completes > synchronously and is no longer replaced by a second parser-generated > document. Commit [e0796020] added the new page dialog in website, and used empty iframes to load each page template. Commit [edf81c13] added the add snippets dialog in website, and used an empty iframe to load the snippets previews. In both cases, before Firefox' fix, it meant we had to wait the recreation of the 2nd document before proceeding. This is no longer the case in Firefox >= 148. [release notes]: https://www.firefox.com/en-US/firefox/148.0/releasenotes/ [e0796020]: https://github.com/odoo/odoo/commit/e0796020ee0c3188e1e9d9fa077de73a2211c6f7 [edf81c13]: https://github.com/odoo/odoo/commit/edf81c13d8f2f6d29a77d68cbfa0dc9216da3c2a Forward-Port-Of: odoo/odoo#250592
This update fixes an error in the Spanish Profit & Loss reports. Accounts 7950 and 7957 were previously incorrectly placed in section 10, which is not compliant with Spanish tax regulations. This change ensures accurate reporting according to official tax documentation.
Original PR description
In the Profit & Loss reports, accounts 7950 and 7957 were incorrectly shown in section 10 instead of section 6 These accounts appear only for non-SME fiscal localization packages According to the official Spanish tax documentation, these accounts should belong to section 6 and not section 10: https://www.boe.es/buscar/act.php?id=BOE-A-2007-19884 opw-5363664 Forward-Port-Of: odoo/enterprise#108575 Forward-Port-Of: odoo/enterprise#107949
This update resolves an issue in the delivery app where the location selector would incorrectly focus when no delivery location was chosen. The fix prevents the selector from gaining focus unnecessarily, improving the user experience and preventing potential confusion. This ensures a smoother and more reliable process for users managing deliveries.
Original PR description
Forward-Port-Of: odoo/odoo#250680
This update resolves an issue where a 100% discount on German Point of Sale (POS) orders was causing an error. The change ensures the system handles this scenario correctly, preventing disruptions to the sales process. This improves the reliability of the German POS functionality.
Original PR description
Backport of https://github.com/odoo/enterprise/pull/98869 opw-5240429 Forward-Port-Of: odoo/enterprise#108561
This update fixes a minor issue where errors related to asset loading after a tour ended were being incorrectly flagged. The change ensures that these 'failed to fetch' errors are now handled more effectively, preventing unnecessary notifications and improving the overall user experience. This is a routine maintenance update.
Original PR description
Similarly to commit https://github.com/odoo/odoo/commit/493bab4f460dd4069d5cb6805933b8088067ff17 hiding "failed to fetch" errors, this commit adds AssetsLoadingError as those represents "just" another category of failed assets request (i.e. lazy loaded) after tour termination. runbot-233826 Forward-Port-Of: odoo/odoo#248003
This update fixes a rounding discrepancy in early payment discounts, particularly when 'Always (upon invoice)' cash discount tax reduction is used. Previously, discounts were calculated line-by-line, leading to minor discrepancies. This change ensures discounts are rounded globally for accurate calculations, improving financial reporting.
Original PR description
**PROBLEM** There is a rounding issue with early payment discount when cash discount tax reduction is set to always (upon invoice). The move.line created for the discount is computed by applying the discount to each line, rounding each line individually. But the early payment discount is computed by rounding globally. **STEP TO REPRODUCE** 1. Create a payment term, with early discount of 1%, and cash discount tax reduction set to 'Always (upon invoice)'. 2. Create an invoice with 4 identical lines, unit price 4.76€ and tax 15%. 3. set the payment term on the invoice and save. 4. Go to journal item, early payment discount is 0.20€. 5. toggle discount_amount column on the the journal item tab. 6. notice on the last line, that balance - discount_amount = 0.19€ instead of 0.20€ opw-5865308 Forward-Port-Of: odoo/odoo#247996
This update fixes an error where certain Intrastat codes (99450000, 99500000, 99600000, and 99700000) were incorrectly marked as expired. The change ensures these codes remain active, aligning with official Belgian regulations as outlined in the Intrastat manual. This corrects a potential reporting issue.
Original PR description
99450000, 99500000, 99600000 & 99700000 were erroneously expired. They are still active : https://www.nbb.be/doc/dd/onegate/data/intrastat_manual_basis_en.pdf page 13 Forward-Port-Of: odoo/enterprise#108451