Daily updates from Odoo
Friday, December 19, 2025
14 changes · 17.0
Enhancements to existing features
This update enhances the user experience by providing clearer placeholders for Peppol identifiers and automatically verifying this information when key data changes. A new feature has been added specifically for Belgium, leveraging the VAT number to streamline Peppol identifier verification through the company registry.
Original PR description
This commit improves the UX by displaying more intuitive placeholders for the peppol identifier. The peppol information is also automatically verified when important data changes. It also adds a special case for Belgium in which we try to use the vat number as the peppol identifier with the company registry endpoint. back-port of: https://github.com/odoo/odoo/pull/233160 task: 5172378 Forward-Port-Of: odoo/odoo#240178
Resolved issues and error corrections
This update resolves an issue where the IoT box was incorrectly attempting to check out the correct Git branch when no database connection was present. This change improves stability and efficiency by avoiding unnecessary Git operations, ensuring the IoT box functions reliably.
Original PR description
This PR ignores the call to check_git_branch if no database is connected to the iot box.
This pull request resolves a bug related to FRGI testing within the Odoo spreadsheet module. The fix ensures accurate results are displayed during FRGI testing processes, improving data reliability. This update addresses a previously reported issue impacting spreadsheet functionality.
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update fixes an issue where DIN5008 invoices weren't showing Incoterm information. The change adds the necessary logic to include Incoterm codes and locations on these invoices, ensuring compliance with DIN5008 reporting requirements. This improves invoice accuracy and reporting for international transactions.
Original PR description
**Steps to reproduce:** 1. Install the modules account and l10n_din5008. 2. Go to Settings and set DIN5008 as the default invoice report template. 3. Navigate to Configuration → Settings and set a default Incoterm. 4. Create a new customer invoice. 5. Print the DIN5008 Invoice Report. **Issue:** The DIN5008 invoice report did not display the Incoterms, while other invoice layouts printed them correctly. **Cause:** This was due to missing logic in l10n_din5008 report to include Incoterm data. Confirmed with TSB that the DIN5008 layout should display Incoterms. **Fix:** This commit adds the Incoterm information to the DIN5008 template data: - Always include the Incoterm code - If an Incoterm location is set, display it as `CODE - LOCATION` **opw-5349267**
This update fixes an issue where users could inadvertently create invalid fields within SQL view models, like the 'sale_report'. Previously, manual creation of these fields caused disruptions to workflows. This change prevents the creation of these fields through Studio, ensuring data integrity and stability.
Original PR description
Prevent creating fields on SQL views ### Impacted versions: 17.0 and later ### Steps to reproduce: Create a new field on sale_report Open sales -> reporting -> sales -> measures ### Current behavior: When you try to create fields with Studio on models based on SQL views such as sale_report you will get a user error. However it's still possible to create these fields manually, which consequently will break some flows and it doesn't make sense to add fields Task: [5394158](https://www.odoo.com/odoo/project/49/tasks/5394158)
This update resolves a bug where the 'convert to task' option repeatedly appeared for converted Todos, causing confusion. The fix hides this option when a project is assigned, streamlining the task conversion process and improving user experience. This ensures consistent behavior when managing tasks within Odoo.
Original PR description
Steps to reproduce: - Create a Todo and convert into task using cog Menu option. - Todo is converted to task and is displayed. - Through breadcrumb go back to Todo - Try to convert it again Issue: - The converted todo is again converted (change of project etc) Fix: - Hiding the convert cog menu when a project is set. task-5075327
This update fixes a layout issue that occurred when tax group names were too long, causing the tax totals component to display incorrectly. The change adds text wrapping to the tax group labels, ensuring the interface remains readable and the display is consistent, even with lengthy tax descriptions.
Original PR description
When tax group names or tax-related content are too long, they break the layout of the tax totals component, causing display issues and making the interface difficult to read. This change adds the Bootstrap `text-wrap` class to the tax group label to enable text wrapping, ensuring that long content is properly contained within the table cell and the layout remains intact. The `text-wrap` utility class applies `word-wrap: break-word` and `word-break: break-word`, which allows long text to wrap to multiple lines instead of overflowing and breaking the table layout. Before: <img width="1920" height="868" alt="image" src="https://github.com/user-attachments/assets/cdf770ca-a586-487e-9283-45463ef4dc0e" /> After <img width="1920" height="793" alt="image" src="https://github.com/user-attachments/assets/24b9781c-d209-4a69-824c-13a59a8c9bc7" /> --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update resolves an issue where user activity wasn't accurately tracked, causing the presence status to incorrectly remain 'away'. By enabling event capturing, the system now reliably detects user clicks and updates the presence status to 'online' as expected. This ensures accurate user activity monitoring.
Original PR description
Before this PR, Elements that stopped event propagation (e.g., using event.stopPropagation()) prevented the global click listener from firing. As a result, user activity wasn't detected, and the presence status stayed "away" instead of switching back to "online". This PR fixes the issue by enabling event capturing on the global click listener (useCapture: true). With capture mode, the listener receives the event during the capture phase before any element can stop propagation. Bug:  task-[4892229](https://www.odoo.com/odoo/project/1519/tasks/4892229)
This update fixes an error in how sales margins are calculated for multi-currency POS orders. The previous calculation was producing an incorrect margin figure. The fix ensures accurate margin reporting by applying the correct formula, resulting in more reliable sales data.
Original PR description
Step to reproduce: - create new journal and a pricelist with different currency (TWD) - set that pricelist and journal in a pos - have a product with sales(1000$) and cost price(300$) - create pos and finalize the order with that product - go to sales > reporting > sales > pivot view - check margin for that order Observation: - the margin is calculated wrong due to improper brackets - current calculation (for TWD pricelist, multiply with currency rate i.e 36.833) sale price - ( cost price / currency rate) i.e. `1000 * 36.833 - (300* 36.833 / 36.833) = 36833 - 300 = 36533` Fix: - fixed the calculation, used brackets - actual calculation - `(1000 * 36.833 - 300 * 36.833) / 36.833 = 1000 - 300 = 700` Note: Backkport of #239407 opw-5166714 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update significantly speeds up product searches used in EDI invoice processing, particularly for PEPPOL transactions. By restructuring the database query, the system now utilizes indexes more effectively, dramatically reducing processing times. This improvement is crucial for handling large volumes of invoices efficiently.
Original PR description
The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents…
The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents Postgres from utilizing indexes. This becomes a problem in databases with a large number of products since a seq scan would be very slow. This commit changes the way this is done by performing separate queries instead of a single query with multiple conditions within an OR statement. Although this might seem a performance degradation, it actually allows these separate queries to utilize indexes and run much faster compared to the original approach. It also simplifies the priority logic and allows for faster early exits compared to the original one. This function is mainly used with EDI crons (such as PEPPOL where this problem was noticed), which could require hundreds of product searches as it does a search per invoice line. Benchmarks: Importing a peppol document of 173 invoice lines. | Num products | Num invoice lines | Before | After | | ------------ | ----------------- | -------- | ------- | | 864873 | 173 | 868.18 s | 19.43 s | | 397005 | 173 | 468.91 s | 20.68 s | | 8064 | 173 | 125.08 s | 20.1 s | | 564 | 173 | 119.9 s | 20.21 s | opw-5245007 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#238853
This update resolves a bug where invoices using the Solucion Factible PAC were being rejected due to incorrect exchange rate precision. The fix ensures the exchange rate is rounded to 6 decimal places, aligning with requirements for Mexican tax compliance (CFDI). This prevents invoice errors and ensures smooth payment processing.
Original PR description
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request…
The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs. Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs. [opw-5165200](https://www.odoo.com/odoo/project.task/5165200) ## Steps to reproduce: [Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing) 1. Navigate to Apps and install l10n_mx_edi. 2. Switch to any of the Mexican companies that appear. 3. Navigate to Accounting > Configuration > Currencies. 4. Click into the USD currency. 5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field). 6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible. [Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing) 1. Navigate to Accounting > Customers > Invoices. 2. Select New to create a new invoice. 3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES). 4. Add the 45 day Payment terms. This should change the payment policy to PPD. 5. Change the currency to USD. 6. Add the product FURN_8220 (or any with the unspsc_code_id set). 7. Set the unit price of the product to 58968.29. 8. Confirm the invoice. 9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again. 10. Select Register Payment, then Confirm Payment. 11. Select the Update Payments smart button. 12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.
This update fixes a frustrating user experience where inline code snippets were difficult to remove from the Odoo web editor, particularly within lists. The change ensures that the code style disappears automatically when the last character of the code is deleted, streamlining the editing process and improving usability.
Original PR description
Text formatted as inline `<code>` (between backticks) is very difficult to remove in some situations, typically at the beginning of a list entry. This commit solves this by removing the code style when its last character is removed. Steps to reproduce: - Create a list - Type some inline code - Put the cursor in the middle - Press Enter - Type some text after the inline code on the second line - Try to remove the inline code from the second line using backspace => The line is removed before the code style disappears task-5375140
This update resolves a memory issue that occurred when generating reports in the Odoo Enterprise system. The fix optimizes how data is retrieved from the database, preventing the system from running out of memory and crashing. This ensures reports can be generated reliably, especially for large customer databases.
Original PR description
- The method _compute_l10n_in_transaction_type currently fetches all columns…
- The method _compute_l10n_in_transaction_type currently fetches all columns https://github.com/odoo/enterprise/blob/1a67dadd2b1b3f94125f4088d1c36a77057443b4/l10n_in_reports/models/account_move.py#L20-L29
from the account_move table, whereas only a subset of fields is actually
required. Since account_move is typically a large table in customer databases,
this approach can lead to high memory consumption and potentially result in
MemoryError.
- I used the fetch method to ensure that non-stored fields are ignored and that only the specified fields are retrieved from the database, fetching only what is strictly necessary.
https://github.com/odoo/odoo/blob/574a67c73633755438d0aff7ff85f380fec9ef0d/odoo/models.py#L3826-L3830
- Moreover, this fix is implemented in version 18.0. As a result, it is not
applied in version 17.0, which explains why the MemoryError occurs in that
version.
https://github.com/odoo/enterprise/pull/76502/commits/be655971e7059b79bc3200b83d5e76b3c0b12059
```python3
Traceback (most recent call last):
File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1374, in preload_registries
registry = Registry.new(dbname, update_module=update_module)
File "<decorator-gen-16>", line 2, in new
File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
return func(inst, *args, **kwargs)
File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 110, in new
odoo.modules.load_modules(registry, force_demo, status, update_module)
File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 519, in load_modules
migrations.migrate_module(package, 'end')
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 221, in migrate_module
exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 239, in exec_script
migrate(cr, installed_version)
File "/tmp/tmp259m4qqf/migrations/l10n_mx/saas~16.2.2.0/end-migrate.py", line 9, in migrate
CoA.try_loading("mx", company=company, install_demo=False)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 155, in try_loading
return self._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/point_of_sale/models/chart_template.py", line 22, in _load
result = super()._load(template_code, company, install_demo)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 215, in _load
self._load_translations(companies=company)
File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 1351, in _load_translations
translation_importer.save(overwrite=False)
File "/home/odoo/src/odoo/17.0/odoo/tools/translate.py", line 1460, in save
env.flush_all()
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 737, in flush_all
self._recompute_all()
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 733, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6977, in _recompute_field
field.recompute(records)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1379, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1352, in apply_except_missing
func(records)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 431, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/enterprise/17.0/l10n_in_reports/models/account_move.py", line 23, in _compute_l10n_in_transaction_type
if move.country_code == "IN":
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 431, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
return needle(records, *args)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
values = [first(value[name]) for value in values]
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__
return self._fields[key].__get__(self, self.env.registry[self._name])
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query
self.env.cache.insert_missing(fetched, field, values)
File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing
field_cache.setdefault(id_, val)
MemoryError
select COUNT(*) from account_move
+--------+
| count |
|--------|
| 511738 |
+--------+
SELECT 1
Time: 0.177s
```
opw-5414648
upg-3570209This update fixes an issue where marketing automation emails weren't displaying translated text when run through the Odoo cron job. The problem stemmed from a language context being overwritten, preventing the correct translation of dynamic fields like email titles. This change ensures all marketing automation emails are translated accurately, regardless of how they are triggered.
Original PR description
We have a dynamic placeholder in the marketing automation's mail template like object.title.name. Odoobot's preferred language is, let's say "Dutch". When the marketing automation is tested manually, with the user whose language is "Dutch", the field is translated fine. But when ran vai cron, "Marketing Automation: execute activities", the field isn't translated properly, because the context with lang Dutch gets overwritten earlier in the process. To fix this, we add a lang context right before the execution. Step To Reproduce: 1.Create a marketing automation. 2.In the mail template, add a dynamic placeholder with field object.title.name. 3.Switch the Odoobot's preferred language to anything but English. But here let's say "Dutch". 4.Now, switch to superuser, and then run the cron manually. 5.We can see that the title didn't get translated properly. opw-5062328