Odoo Changelog — 2025-07-02

Wednesday, July 2, 2025

6 changes · master

Bug Fixes(6)

Resolved issues and error corrections

[FIX] account_online_synchronization: Prevent blocking error on currency mismatch

Enterprisemasteraccount_online_synchronizationMEDIUM

Connecting a journal to an online bank account will no longer fail when Odoo Fin provides a preset currency that conflicts with existing journal or bank account entries. Instead, the currency update is skipped so users can complete the synchronization without being blocked.

Original PR description

This commit avoids blocking users when connecting a journal to an online account that has a predefined currency.

Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion.

Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed.

opw-4751616

Forward-Port-Of: odoo/enterprise#89042
Forward-Port-Of: odoo/enterprise#88654

#bank synchronization#currency#journals

[FIX] l10n_es_reports: include fully cancelled lines boe mod 349

PR #89130

Enterprisemasterl10n_es_reportsMEDIUM

The Spanish Mod 349 BOE export now includes mandatory rectification entries when an earlier invoice is fully cancelled by a credit note. It also prevents draft or reverted invoices from being incorrectly included, improving tax report accuracy and compliance.

Original PR description

How to reproduce the issue:

With l10n_es on an ES company:
- Create an invoice from two months ago with a value of 1000.
- Fully credit note this invoice on the current month.
- On the mod 349 report, download the BOE report.

The BOE report does not contains the rectification despite being mandatory as per:
https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 (look at the examples in CUMPLIMENTACIÓN DEL REGISTRO DE RECTIFICACIONES).

This commit also fixes an issue where invoice reverted to draft where included in the boe report:
- Create an invoice of 100 in January, credit note 50 in May.
- Reset to draft both the invoice and the credit note.
- Create another invoice of 888 in February, credit note 444 in May.
- Generate the BOE report.

The invoice reverted to draft is included in the boe report.

opw-4653025

Forward-Port-Of: odoo/enterprise#88625
Forward-Port-Of: odoo/enterprise#86127

#spain#tax-reporting#mod-349#boe#compliance

[FIX] _*: fix the planned hours for "Material" type resources

PR #89213

Enterprisemastersale_planningsale_renting_planningMEDIUM

Rental orders using material resources now count their planned hours correctly. This prevents already-planned rental shifts from being shown as still needing planning, giving sales and planning teams a more accurate order status.

Original PR description

_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to…

_*= sale_planning, sale_renting_planning

Steps to Reproduce:
- Install the `sale_renting_planning` module.
- Create a rental product with the `Plan Service` enabled and the resource type set to `Material`.
- Create a SO for the newly created product and confirm it.
- Observe the state button the shift is already planned but it incorrectly displays `To Plan`.

Issue:
- Confirming the SO the shift is already planned but the state button still displays `To Plan`. this issue occurs when the resource type is `Material` However it works correctly when the resource type is `User`.

Cause:
- When we are calculating the planned hours the domain `'resource_type', '!=', 'material'` is passed causes resources type of Material so it will be excluded from the calculation.

Fix:
- In this commit removed the condition that excluded resources of type Material so that they are included when calculating the planned hours. This ensures the state button shows the correct status.

task-3978597

Forward-Port-Of: odoo/enterprise#75861

#rental#planning#material resources#sales orders

[REF] documents{_spreadsheet}: replace bootstrap dropdown with odoo d…

PR #82434

Enterprisemasterdocumentsdocuments_spreadsheetMEDIUM

The Documents app now uses Odoo's own dropdown menu for the New button instead of an older Bootstrap component. This prevents memory usage from growing when users repeatedly open the menu, improving stability in Documents and spreadsheet creation flows.

Original PR description

…ropdown

Before this commit, the Documents control panel was still using a Bootstrap dropdown. This caused a memory leak, as the dropdown wasn't properly destroyed when the control panel itself was removed.

The issue was identified while working on spreadsheet tests, where the Documents control panel was used to create a new spreadsheet. However, the memory leak is also reproducible in production code.

To observe it:
- Open the document app
- Click on the New button in the control panel
- Inspect elementsMap in bootstrap/data.js

You'll notice that elementsMap keeps growing as you repeat the action.

Possible fix (not chosen): Manually destroy the Bootstrap dropdown Drawbacks:
- There's no clean hook to do it. For example, willUnmount might be too late if the dropdown is conditionally rendered via t-if, and already removed from the DOM.
- We aim to avoid Bootstrap JS in Odoo's backend, partly due to issues like this.

Final solution (chosen in this commit):
Replace the Bootstrap dropdown with the native Odoo dropdown component.

Graph with the impact on the memory usage in the tests:
<img width="1435" alt="image" src="https://github.com/user-attachments/assets/ae01222f-393b-474b-a1e7-6d6961270fc7" />

#memory-leak#dropdown#stability

[FIX] helpdesk: prevent mail scanners from closing tickets

PR #89097

EnterprisemasterhelpdeskMEDIUM

Helpdesk tickets will no longer be closed when automated email scanners check links in customer emails. This prevents tickets from being marked closed without a real customer action, keeping support workflows accurate.

Original PR description

Currently some customers with email scanners will have their ticket closed soon after it's opened.

Steps to reproduce
-----
1. Enable "Closure by Customers" on the helpdesk team
2. Create a new ticket
3. Send a HEAD request to the "Close ticket" link in the received email, using `curl -I <url>`
4. The ticket gets closed

Cause
-----
Some email scanners send HEAD requests to links contained in emails, which is incorrectly interpreted as a user action.

Fix
-----
Implement a check so that only GET requests to the route will close the ticket.

opw-4837167

Forward-Port-Of: odoo/enterprise#89026
Forward-Port-Of: odoo/enterprise#88547

#helpdesk#tickets#email#portal

[FIX] mrp_barcode: avoid duplicata in barcode quant cache

PR #89104

Enterprisemasterstock_barcodeMEDIUM

Fixed an issue in barcode inventory counts where scanning the same product after removing a line could create repeated sublines. This keeps stock counting screens clearer and helps users avoid confusion or potential counting mistakes.

Original PR description

### Steps to reproduce:

- Create a storable product with 1 unit in stock and a barcode: XXX
- Go to the barcode app > Inventory Count
- Scan XXX
> One line is created 1/1.
- Diminish the quantity to 0 > Remove the line
- Scan XXX
#### > The line appear with multiple sublines
#### > If you repeat the two last steps even more sublines will appear

### Cause of the issue:

Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L345 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L359-L381 However, the quants present in the cache are currently stored in a list and they are pushed to the list by the `setCache` method even if they are already present:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L54-L62 This is problematic in the present flow since multiple actions set the cahche and hence add the "new" version of the already present quant rather than updating its current value.

To be more precise, in the present workflow, the `setCache` method is called once during the the first barcode scan:
https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L324-L325 And twice at each line deletion (once per `refreshCache` call, one during the save and one during the `trigger('refresh')`): https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L823-L825 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L468-L471

opw-4787229

Forward-Port-Of: odoo/enterprise#88861
Forward-Port-Of: odoo/enterprise#87073

#barcode#inventory#stock-count#duplicates

This commit avoids blocking users when connecting a journal to an online account that has a predefined currency. Previously, if the journal or its default bank account had entries in a different currency than the one sent by Odoo Fin, the process would fail with an error, preventing completion. Now, the system silently ignores the currency mismatch error and skips setting the currency, allowing the synchronization to proceed. opw-4751616 Forward-Port-Of: odoo/enterprise#89042 Forward-Port-Of: odoo/enterprise#88654

How to reproduce the issue: With l10n_es on an ES company: - Create an invoice from two months ago with a value of 1000. - Fully credit note this invoice on the current month. - On the mod 349 report, download the BOE report. The BOE report does not contains the rectification despite being mandatory as per: https://www.boe.es/buscar/doc.php?id=BOE-A-2010-5098 (look at the examples in CUMPLIMENTACIÓN DEL REGISTRO DE RECTIFICACIONES). This commit also fixes an issue where invoice reverted to draft where included in the boe report: - Create an invoice of 100 in January, credit note 50 in May. - Reset to draft both the invoice and the credit note. - Create another invoice of 888 in February, credit note 444 in May. - Generate the BOE report. The invoice reverted to draft is included in the boe report. opw-4653025 Forward-Port-Of: odoo/enterprise#88625 Forward-Port-Of: odoo/enterprise#86127

_*= sale_planning, sale_renting_planning Steps to Reproduce: - Install the `sale_renting_planning` module. - Create a rental product with the `Plan Service` enabled and the resource type set to `Material`. - Create a SO for the newly created product and confirm it. - Observe the state button the shift is already planned but it incorrectly displays `To Plan`. Issue: - Confirming the SO the shift is already planned but the state button still displays `To Plan`. this issue occurs when the resource type is `Material` However it works correctly when the resource type is `User`. Cause: - When we are calculating the planned hours the domain `'resource_type', '!=', 'material'` is passed causes resources type of Material so it will be excluded from the calculation. Fix: - In this commit removed the condition that excluded resources of type Material so that they are included when calculating the planned hours. This ensures the state button shows the correct status. task-3978597 Forward-Port-Of: odoo/enterprise#75861

…ropdown Before this commit, the Documents control panel was still using a Bootstrap dropdown. This caused a memory leak, as the dropdown wasn't properly destroyed when the control panel itself was removed. The issue was identified while working on spreadsheet tests, where the Documents control panel was used to create a new spreadsheet. However, the memory leak is also reproducible in production code. To observe it: - Open the document app - Click on the New button in the control panel - Inspect elementsMap in bootstrap/data.js You'll notice that elementsMap keeps growing as you repeat the action. Possible fix (not chosen): Manually destroy the Bootstrap dropdown Drawbacks: - There's no clean hook to do it. For example, willUnmount might be too late if the dropdown is conditionally rendered via t-if, and already removed from the DOM. - We aim to avoid Bootstrap JS in Odoo's backend, partly due to issues like this. Final solution (chosen in this commit): Replace the Bootstrap dropdown with the native Odoo dropdown component. Graph with the impact on the memory usage in the tests: <img width="1435" alt="image" src="https://github.com/user-attachments/assets/ae01222f-393b-474b-a1e7-6d6961270fc7" />

Currently some customers with email scanners will have their ticket closed soon after it's opened. Steps to reproduce ----- 1. Enable "Closure by Customers" on the helpdesk team 2. Create a new ticket 3. Send a HEAD request to the "Close ticket" link in the received email, using `curl -I <url>` 4. The ticket gets closed Cause ----- Some email scanners send HEAD requests to links contained in emails, which is incorrectly interpreted as a user action. Fix ----- Implement a check so that only GET requests to the route will close the ticket. opw-4837167 Forward-Port-Of: odoo/enterprise#89026 Forward-Port-Of: odoo/enterprise#88547

### Steps to reproduce: - Create a storable product with 1 unit in stock and a barcode: XXX - Go to the barcode app > Inventory Count - Scan XXX > One line is created 1/1. - Diminish the quantity to 0 > Remove the line - Scan XXX #### > The line appear with multiple sublines #### > If you repeat the two last steps even more sublines will appear ### Cause of the issue: Scaning XXX will create a line with a subline for each quant present in the lazyBarcodeCache: https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L345 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_quant_model.js#L359-L381 However, the quants present in the cache are currently stored in a list and they are pushed to the list by the `setCache` method even if they are already present: https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L54-L62 This is problematic in the present flow since multiple actions set the cahche and hence add the "new" version of the already present quant rather than updating its current value. To be more precise, in the present workflow, the `setCache` method is called once during the the first barcode scan: https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/lazy_barcode_cache.js#L324-L325 And twice at each line deletion (once per `refreshCache` call, one during the save and one during the `trigger('refresh')`): https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L823-L825 https://github.com/odoo/enterprise/blob/585b251a857f74cd7dce3be67471c54d8d617fac/stock_barcode/static/src/models/barcode_model.js#L468-L471 opw-4787229 Forward-Port-Of: odoo/enterprise#88861 Forward-Port-Of: odoo/enterprise#87073