Daily updates from Odoo
Wednesday, July 2, 2025
11 changes · master
New functionality added to Odoo
VoIP users can now access CRM leads directly from contact-related areas in the softphone, making it easier to connect calls with sales opportunities. The change also generalizes shared VoIP extension points so similar buttons can be reused across related apps.
Original PR description
This commit adds a button that connects the contacts to its leads via the VoIP module. It uses the same logic as "Applicant" button introduced before. Task-4855484 Community: https://github.com/odoo/odoo/pull/214031 Forward-Port-Of: odoo/enterprise#88960 Forward-Port-Of: odoo/enterprise#87294
Spreadsheet users can now create selection-based filters in addition to existing filter options. This makes it easier to narrow spreadsheet data using predefined choices, improving analysis and reporting workflows.
Original PR description
See community commit for details. Task: 3619413
Enhancements to existing features
Bank statement reconciliation now avoids matching entries that include cash or credit card account lines when that would create invalid statement entries. This helps prevent reconciliation errors caused by multiple cash or bank accounts appearing on the same statement move.
Original PR description
In this commit: https://github.com/odoo/enterprise/commit/c0f8c5d17b9d78b640d744d8bfb6a2bb4002776a We changed a condition to have the possibility to match move with an account that allows the reconciliation but by doing so, we authorize moves with a cash line to be match. This will trigger a constraint since we cannot have multiple cash or bank accounts on the same statement move. To avoid that we add a condition that the type of the account can be reconcile but is not an asset_cash or liability_credit_card no task id Forward-Port-Of: odoo/enterprise#88659
Payroll pay runs can now generate payslips from selected employees as well as payroll versions, making the process easier when contract details are not selected directly. This improves payroll workflow flexibility while preserving automatic selection of valid contracts for the pay run period.
Original PR description
Problem ---------- Generation of payslip with valid_versions is not enough flexible With work entries, we have to generate payslips for employees. Objective ---------- Change the _get_valid_versions_domain to _get_valid_versions to get only ids Adapt the signature of generate_payslips to use employees or versions to generate payslips Solution ---------- Now the _get_valid_versions give the valid versions ids, so we can directly browse them or add them in a domain, the domain is not forced The generate_payslips can work with versions (first argument by default) and employees, if employee_ids are given, this will fetch valid versions for these employee depending on the pay run config directly. So via the front, we can call generate_payslips with a list of employees if we don't have versions directly. (it will automatically select all contracts valid in the range of payrun as before with contracts) task-4900019 Forward-Port-Of: odoo/enterprise#88768
Egypt and Saudi Arabia payroll setups now include default working calendars that better match local standard schedules. Demo companies, employee contracts, and payroll structures are aligned with these calendars, improving payroll configuration accuracy for those countries.
Original PR description
*: sa,eg - add a new calendar that match the std working schedule for those countries and assign it to thier demo comapny, employees contracts and payroll structure Task: 4724754
Resolved issues and error corrections
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
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
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
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…
…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" />
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
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…
### 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