Monday, December 15, 2025
15 changes · 18.0
Resolved issues and error corrections
This update fixes an issue where the system incorrectly processed vendor bills with a zero unit price in Italian e-invoicing (l10n_it_edi). The fix ensures the system correctly incorporates the zero price from the XML, preventing errors and ensuring accurate e-invoice generation. This improves compliance with Italian tax regulations.
Original PR description
**Steps to reproduce:** * Install the **Italy – E-invoicing (l10n_it_edi)** module. * Create a product with a non-zero cost price. * Create a **vendor bill** for an Italian vendor using the **RC…
**Steps to reproduce:** * Install the **Italy – E-invoicing (l10n_it_edi)** module. * Create a product with a non-zero cost price. * Create a **vendor bill** for an Italian vendor using the **RC fiscal position**. * Add the product with **unit price = 0**, apply **RC tax**, and set the **Origin Document Type**. * Confirm the bill and click **Send to Tax Integration** to generate the XML in the chatter. * Upload the generated XML through **Accounting → Vendors → Bills → Upload**. **Observed behavior:** * The imported bill ignores the XML value **0.00** and uses the product's default price instead. **Cause:** * The XML’s `<PrezzoUnitario>` value is mandatory and may be **0**, but the code skipped it because `0.0` evaluates as falsy in the walrus assignment. **Fix:** * Always set the parsed `PrezzoUnitario` value (including **0.0**) on the invoice line. ref: https://fex-app.com/FatturaElettronica/FatturaElettronicaBody/DatiBeniServizi/DettaglioLinee/PrezzoUnitario opw-5322187 Forward-Port-Of: odoo/odoo#239419
This update fixes a performance issue where Odoo was unnecessarily calculating field values for inherited fields. By preventing these calculations, the system now runs more efficiently, especially when dealing with complex data relationships. This change improves overall Odoo responsiveness and stability.
Original PR description
when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it…
when the ``get_description`` is calling. So, it getting all the information weather it's groupable or not for it [here](https://github.com/odoo/odoo/blob/b48d41086d7ff8ef91c6c43d37d588686d6b921a/odoo/orm/fields.py#L923) and field is from inherited model it trying ``model._read_group_groupby(model._table, groupby, query)`` because those related and non store. As there is no meaning for computation for that because it going groupable because it parent_field is groupable. So, keeping check for that and reduce the computation.
```
File "/tmp/tmpmagm1mli/migrations/base/tests/test_mock_crawl.py", line 430, in mock_act_window
views = get_views(
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_thread.py", line 463, in get_views
res = super().get_views(views, options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/models.py", line 10, in get_views
result = super().get_views(views, options=options)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_ui_view.py", line 52, in get_views
return super().get_views(views, options)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_ui_view.py", line 2935, in get_views
result['models'][model] = {"fields": self.env[model].fields_get(
File "/home/odoo/src/odoo/19.0/addons/stock/models/product.py", line 521, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/enterprise/19.0/web_studio/models/ir_model.py", line 76, in fields_get
return super().fields_get(allfields, attributes=attributes)
File "/home/odoo/src/enterprise/19.0/ai_fields/models/models.py", line 47, in fields_get
res = super().fields_get(allfields, attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3360, in fields_get
description = field.get_description(self.env, attributes=attributes)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 883, in get_description
value = value(env)
File "/home/odoo/src/odoo/19.0/odoo/orm/fields.py", line 930, in _description_groupable
model._read_group_groupby(model._table, groupby, query)
File "/home/odoo/src/odoo/19.0/addons/mail/models/mail_activity_mixin.py", line 259, in _read_group_groupby
return super()._read_group_groupby(alias, groupby_spec, query)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 2064, in _read_group_groupby
coquery = comodel._search(codomain, bypass_access=field.bypass_search_access)
File "/home/odoo/src/odoo/19.0/odoo/addons/base/models/ir_attachment.py", line 659, in _search
records = self.sudo().with_context(active_test=False).search_fetch(
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 1418, in search_fetch
return self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/19.0/odoo/orm/models.py", line 3914, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
File "/home/odoo/src/odoo/19.0/odoo/orm/environments.py", line 534, in execute_query
self.cr.execute(query)
File "/home/odoo/src/odoo/19.0/odoo/tests/test_cursor.py", line 79, in execute
return self._cursor.execute(*args, **kwargs)
File "/home/odoo/src/odoo/19.0/odoo/sql_db.py", line 426, in execute
self._obj.execute(query, params)
psycopg2.DatabaseError: out of memory for query result
```
opw-5260147
upg-3444635
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis update fixes an issue where unnecessary slashes ('/') were appearing in tax reports' XML output when there was no comment provided. Removing this slash ensures the reports are correctly formatted and compatible with accounting systems. This change improves data accuracy and avoids potential reporting errors.
Original PR description
Since 17.0, we added a / when there was no comment in the comment section of the xml. This is wrong and should be left empty. opw-5242381 Forward-Port-Of: odoo/enterprise#100033
This update resolves a visual glitch where dynamic website snippets would appear and disappear unexpectedly. The issue stemmed from a recent change in how snippets are styled, and this commit restores the original behavior of making snippets initially hidden, allowing content to determine their visibility. This ensures a consistent and reliable user experience.
Original PR description
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]-…
Steps to reproduce [18.2+]: 1. Add a dynamic snippet to a website page (e.g., Events). 2. Unpublish all event records. 3. The snippet first appears with a visible header, which then disappears. [A]- Starting from [1], the `o_dynamic_empty` class was introduced to handle the dynamic snippets visibility, and an upgrade script (see [3]) set this class by default on them. Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in the XML template, while on the JS side, the class used to toggle snippet visibility was `o_dynamic_snippet_empty`. This class was also added to snippets on destroy (before saving). [B]- As a result, a dynamic snippet may end up with: - `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but edited snippets. - `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0. - `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created in 18.0. Remark: the `s_dynamic_empty` class was introduced by mistake and does not have any associated CSS Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the interaction flow became inconsistent (starting from 18.2): snippets were initially visible, then hidden if no content was found... which caused the flickering behavior described above. And because of [B], old snippets with the `o_dynamic_empty` class will be visible by default in 18.0. This commit restores the intended (and original) behavior: - A dynamic snippet should be invisible by default, - Then the interaction decides (based on actual content) whether the snippet should be displayed. [1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878 [2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b [3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906 opw-5354523
This update resolves a minor visual glitch where the caret (cursor) within the record selector component was causing unexpected changes to the input field's width. This ensures a consistent and properly sized user interface for selecting records, improving the overall user experience.
Original PR description
This commit fixes an issue where, when visible, the caret of the record selector component would take space and thus change the width of the input. Task: [5354466](https://www.odoo.com/odoo/project/133/tasks/5354466) --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#237054
This update resolves an issue where users couldn't rename the "Help" menu item in the website helpdesk, encountering an error related to the 'website form' feature. Now, users can directly edit the name of this menu item, improving usability and flexibility within the helpdesk interface.
Original PR description
**Issue** It was not possible to rename the "Help" menu item, an error appeared with the message: "This URL is reserved for the helpdesk teams with 'website form' feature enabled.", even if the user was not trying to edit the URL. **Change** Allow the user to edit the menu item's name. opw-5375334 Forward-Port-Of: odoo/enterprise#101323
This update resolves an issue where loading demo data in a newly created company within the Appraisal module would fail due to permission restrictions. The fix ensures demo employee data is created within the current company, eliminating the access error and allowing users to successfully load sample data.
Original PR description
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module. **Steps to Reproduce:** 1. Install `hr_appraisal` without demo data. 2. Create a…
Currently, an error occurs when a user attempts to load demo data for a newly created company in the Appraisal module.
**Steps to Reproduce:**
1. Install `hr_appraisal` without demo data.
2. Create a new company and switch to it.
3. Appraisals > Click "Load sample data".
**Traceback:**
```
AccessError
Uh-oh! Looks like you have stumbled upon some top-secret records.
Sorry, Sengsourigna Phonkaseumsouk (id=2) doesn't have 'read' access to:
- Employee, Emma Granger (hr.employee: 3, company=TPX Solutions)
Blame the following rules:
- Employee multi-company rule
If you really, really need access, perhaps you can win over your friendly administrator with a batch of freshly baked cookies.
This seems to be a multi-company issue; you might be able to access the record by switching to the company: TPX Solutions.
ParseError
while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside <function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref('hr_appraisal.hr_appraisal_2')]"/>
ValueError
ParseError('while parsing /home/odoo/src/enterprise/18.0/hr_appraisal_skills/demo/scenarios/scenario_appraisal_demo.xml:4, somewhere inside\n<function model="hr.appraisal" name="_copy_skills_when_confirmed" eval="[ref(\'hr_appraisal.hr_appraisal_2\')]"/>') while evaluating 'action = model._load_demo_data()'
```
**Cause:**
The demo data loading process attempts to access employee records without the required permissions. Since the user belongs to a different company, the multi-company security rules prevent reading those employees.
**Fix:**
This commit removes the company assignment from the demo employee records so they are created in the current company instead of the base company.
sentry-7032880299This update resolves an issue in the Mexican tax reporting module (l10n_mx_edi) where test calculations incorrectly rounded payment amounts. The fix ensures that invoice rates are accurately applied during payment processing, improving the reliability of tax reporting. This change addresses a minor discrepancy in the testing process.
Original PR description
The test test_cfdi_rounding_9 artificially make a batch payment for 6 invoices each with a different rate on the same day. After 388ccda652e21a16ea860c1084567f9291fc7d38 the payment amount is computed based on each invoice's rate rather than just the payment date. This commit fixes the values for this test to reflect this change. opw-4846090
This pull request updates the core spreadsheet component (o_spreadsheet) to the latest version within the 18.0 release. These updates address several technical improvements and bug fixes related to spreadsheet functionality and performance, ensuring a smoother user experience. The changes were made by a team of developers to maintain stability and optimize the spreadsheet feature.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6a0e768aee [REL] 18.0.51 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/6a0e768aee [REL] 18.0.51 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/d17a974ba7 [FIX] CorePlugins: Prevent dispatch during adaptRange [Task: 5380747](https://www.odoo.com/odoo/2328/tasks/5380747) https://github.com/odoo/o-spreadsheet/commit/7c2da49579 [PERF] evaluation: cached dynamic dependencies [Task: 5407156](https://www.odoo.com/odoo/2328/tasks/5407156) https://github.com/odoo/o-spreadsheet/commit/cd4deac676 [FIX] cf: conditional formatting preview is truncated for nothing [Task: 5344000](https://www.odoo.com/odoo/2328/tasks/5344000) Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com> Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>
This update enhances Odoo's ability for other modules to customize how activity actions are handled. By separating the action execution step, it allows modules like 'documents' to add specific behaviors without needing to duplicate existing logic. This improves flexibility and integration.
Original PR description
The `openActivityGroup` method in `ActivityMenu` currently handles both the preparation of filters (domains, contexts) and the actual execution of the action. This coupling prevents other modules from intercepting the action execution to inject specific behaviors—such as loading a specific server-side action or specialized views—without completely overriding the method and duplicating the filter logic. This commit extracts the final execution step into a new method `executeActivityAction`. This allows extending modules (e.g., `documents`) to customize the action load (e.g., to ensure specific JavaScript hooks are initialized) while relying on the base implementation for domain and context generation. Task-5187045
This update prevents a traceback error that occurred when creating invoices with journal items that didn't have assigned labels. The code now safely handles missing labels by defaulting to an empty string, ensuring invoice validation can proceed smoothly. This improves the stability of invoice creation processes.
Original PR description
Creating an invoice containing journal items without a label triggers a traceback because the code unconditionally slices the 'name' field (line.name[:64]) without ensuring it is not False. Since 'name' is not a required field on account.move.line, it must be safely handled.
This commit ensures that the label is always a string by falling back to an empty string when the value is missing.
Steps to reproduce the bug:
- Create a storable product
- Create an invoice:
- Add the product to the invoice
- Set any customer
- Go to the journal items tab
- Remove the label of the journal item corresponding to the product
- Try to validate the invoice
- A traceback is raised
opw-5360602
Forward-Port-Of: odoo/odoo#239188This update improves the accuracy of Thai VAT number input within Odoo. It now ensures that only 13-digit numeric VAT numbers are accepted for Thai partners, aligning with Thai regulations. This prevents incorrect data entry and ensures compliance.
Original PR description
This PR adds a validation method check_vat_th() to verify Thai VAT numbers. In Thailand, a VAT number must consist of exactly 13 numeric digits. For partners with country set to Thailand, the system will only allow VAT numbers that are exactly 13 digits long. Total credits go to: [Saran440](https://github.com/Saran440) `<saranl@ecosoft.co.th>` (See PR: https://github.com/odoo/odoo/pull/239164) Enterprise PR: odoo/enterprise#101905 Forward-Port-Of: odoo/odoo#239616
This update corrects a test failure related to VAT number validation for Thailand. After implementing stricter VAT number checks, a test case failed because the previously used value didn't meet the new format requirements. This ensures accurate reporting and compliance for Thai VAT transactions.
Original PR description
Following the implementation of proper validation for VAT numbers for Thailand, this now fails as the one set in the test doesn't follow the proper format. Community PR: odoo/odoo#239616 Total credits to @vin-odoo Forward-Port-Of: odoo/enterprise#101905
This update resolves an issue where optimized Odoo deployments failed due to a missing payment module dependency. The change silently handles the absence of the `payment_stripe` module, preventing errors and ensuring smoother deployments. This improves the reliability of Odoo installations.
Original PR description
Description of the issue/feature this PR addresses: The `payment` module does not declare a dependency on the `payment_stripe` module but the code implicitly depends on it. This makes a problem in optimized deployments where the `payment_stripe` module is not included. Current behavior before PR: Optimized Odoo deployments without `payment_stripe` fail to start because of a `ModuleNotFoundError`. Desired behavior after PR is merged: If the module is not available, the import error is silently ignored and the `is_stripe_supported_country` calculation returns `False`. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where newly duplicated website pages weren't immediately visible in the page list. Users now need to refresh the page after duplicating a page to ensure the new page appears correctly. This improves the user experience and prevents frustration when managing website content.
Original PR description
Steps to reproduce: - Go in website page list - Select a page - Click on actions -> duplicate - Select a name - New page doesn't appear in the list, you need to reload to be able to see it task-5412167 https://github.com/odoo/odoo/issues/225299 Forward-Port-Of: odoo/odoo#239702