Daily updates from Odoo
Friday, February 6, 2026
18 changes · master
New functionality added to Odoo
This update introduces a new priority field across several key Odoo modules – Helpdesk, HR Payroll, MRP PLM, and Quality – to better manage and categorize support requests and tasks. This improved prioritization will allow teams to focus on the most urgent issues and streamline workflows. The change enhances operational efficiency and reporting capabilities within these core business areas.
Original PR description
task-5385387 PR community: https://github.com/odoo/odoo/pull/244673
Enhancements to existing features
This update simplifies the Odoo user interface by consistently using 'Journal Entry' and 'Journal Item' instead of the more technical 'Account Move' terminology. This change improves clarity and usability for users when managing financial records, reducing confusion around the underlying technical models.
Original PR description
*account_accountant,account_fiscal_categories_fleet,account_intrastat, documents_account,esg,hr_payroll_account,l10n_pe_reports Currently we use both the terms "Journal Entry" and "Account Move" in the UI to refer to the technical model `account.move`. The same goes for "Journal Item" and "Account Move Line" for the technical model `account.move.line`. This is confusing for users, especially since the term "Account Move" is more technical and doesn't reflect the actual term in business use. This commit aims to harmonize the terminology by using "Journal Entry" and "Journal Item" consistently in the UI. task-5489700 Related: https://github.com/odoo/odoo/pull/247406
This update significantly speeds up database synchronization by intelligently grouping and processing database requests in parallel. This change reduces synchronization times from 50 seconds to just 15 seconds on our SaaS databases, improving overall system performance and responsiveness. The team also automatically adds the 'https://' scheme to database URLs, preventing user errors and ensuring reliable connections.
Original PR description
With this commit, the requests sent to retrieve the information from the databases are grouped by IP, and each group is treated in parallel using a ThreadPoolExecutor, which uses a pool of 5 times the number of CPUs. On a set of SaaS databases, we reduced the time needed to synchronize 30 databases from 50s to 15s. Forward-Port-Of: odoo/enterprise#106411 Forward-Port-Of: odoo/enterprise#105673
This update ensures that renaming a WhatsApp channel now reflects for all users within the team, rather than just the individual who made the change. This improves consistency and simplifies team communication management within Odoo Enterprise.
Original PR description
Previously, renaming a WhatsApp channel affected only the current user. With this update, the renamed channel is reflected for all users, maintaining consistency across the team. related [PR](https://github.com/odoo/odoo/pull/245879) task-5873798
This update makes the VoIP keypad more intuitive by allowing users to clear the entire input with a long-press on the backspace button, mirroring the behavior of smartphone apps. This change simplifies data entry and reduces errors, improving the overall user experience for VoIP calls.
Original PR description
Wherever the cursor/selection is, long-press on the backspace button of the VoIP keypad now clears the whole input, just like in smartphones phone apps. task-5079459
This update ensures Odoo complies with Mexican tax regulations (SAT) regarding CFDI refunds. Specifically, credit notes for global invoices now include the refund amount and reason, as required by the SAT. The change adjusts how refund descriptions are handled to meet these regulatory requirements.
Original PR description
The SAT specifies how the description of refunded product should be set and specifically for refunds of global invoices it should contain the amount of the return, discount or bonus and why. Currently, Odoo when a credit note of a global invoice is issued, it sets an specific label for the description. To keep with what SAT asks for, we will keep that label only for credit notes of pos global invoices, and for the others, we keep from what the user put as an input on the line task-5170675 target: 19.0 -> master Forward-Port-Of: odoo/enterprise#106424 Forward-Port-Of: odoo/enterprise#97681
Resolved issues and error corrections
This update streamlines the database synchronization process by removing outdated XMLRPC support and improving error handling. The user interface wizard for KPI selection has been simplified, and synchronization errors are now reported clearly instead of disrupting the entire process. This enhances the stability and efficiency of database updates.
Original PR description
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to…
### [IMP] databases: remove xmlrpc fallback for odoo.com Since odoo.com migrated to 19.0, it will always support the json2 API, and XMLRPC support will be dropped on the next version. In order to simplify the code and avoid subsequent requests in case of errors on the json2 API, the XMLRPC fallback is stripped off from `databases.api`. In this commit, we only adapt the tests so that they don't test the fallback to XMLRPC when calling odoo.com. In the next commit, we will remove the dead code. The configuration parameter `databases.odoocom_apiuser` is removed, as well as the corresponding field in the Settings page. ### [FIX] databases: disable the KPI-selection wizard With this commit, we disable the wizard displayed at the end of a synchronization to select which KPIs are added to the properties field. Instead, we always store all the KPIs that are provided by the databases, and the users can still select which ones they want to display on the list view. The wizard is still used in the background for stable compliance, but it is not displayed to the user any more. It will be removed in the next stable version (saas~19.2). Task-id: [5868314](https://www.odoo.com/odoo/project.task/5868314) ### [FIX] databases: handle fetch errors better With this commit, fetching errors like 502 Bad Gateway are handled better, as they are reported as an error message in the final summary instead of interrupting the whole synchronization and showing a traceback to the end user. ### [FIX] databases: synchronize up to immediate_sync_limit databases synchronously Previously, if the number of databases to be synchronized exceeded `databases.immediate_sync_limit`, no databases were synchronized synchronously. Instead, all were queued for a triggered scheduled action. With this commit, the synchronization process will handle up to `immediate_sync_limit` databases synchronously, while the remaining databases will be sent to the scheduled action. Forward-Port-Of: odoo/enterprise#105965 Forward-Port-Of: odoo/enterprise#105176
This update resolves an issue where sale commission IDs exceeded JavaScript's maximum safe integer, causing errors. The fix increases the range of the plan ID, allowing for a significantly larger number of sales plans (from 900 to 90,000) while maintaining security and minimizing potential data conflicts. This improves the system's ability to handle increased sales volume.
Original PR description
Issue: 10^13 was too big of an exponent as such the id generated were bigger than JS limit `Number.MAX_SAFE_INTEGER`, this resulted in the id being rounded to the nearest reprentable integer. Which resulted in a traceback as we were fetching records that didn't exist. This fix allow a bigger margin for the plan_id while keeping the collusion risk equal, as we have the following: - user_id margin is 10^5 - date is in YYMMDD format, so it occupies at most 6 integer - plan_id can thus occupy the space after which is 5 + 6 so 10^11 Only issue possible left with this id generation would be to have user that are 1000 id apart, with same date and same plan. Or that we have too much plan that we exceed the JS limit. Number of plan that can be handled with this change goes from ~900 -> ~90000 which seems reasonable. Forward-Port-Of: odoo/enterprise#106513
This update fixes an issue where Odoo didn't properly account for credit notes during bank reconciliation. Now, when reconciling a bank transaction with a credit note applied to an invoice, the system correctly uses the remaining balance due ($800 in this example) instead of the full invoice amount. This ensures accurate financial reporting.
Original PR description
1. Create an invoice for $1,000 2. Create a credit note of $200 and apply it to the invoice. The invoice is marked 'partially paid.' The remaining due is $800. 3. Create a bank transaction of $700, reconcile with the invoice. 4. Edit the counterpart line, and click "fully paid". >>> Odoo does not consider the credit note and uses the full amount of $1,000 instead of the remaining due of $800 to reconcile. With the refactor of the bank rec, the way the amount is show is computed from econciled_lines_excluding_exchange_diff_ids in apply_amount.js which only takes into account the direct invoice and not the credit notes (in _compute_reconciled_lines_excluding_exchange_diff_ids it take the matched debit and matched credit so only the partial between the transaction and the move) opw-5485663 Forward-Port-Of: odoo/enterprise#105197
This update resolves an issue that occurred when cancelling subscriptions for internal users (like 'Mitchel Admin'). The original system triggered an access error when attempting to update partner records. The fix utilizes 'sudo' to grant necessary permissions, ensuring subscription cancellations for internal users function correctly.
Original PR description
*: sale_subscription_partnership To reproduce: ============= 1/ be sure Marc Demo has only sales admin righ 2/ as admin create a subscription with customer = Mitchel Admin (or other internal user) and confirm it (only confirm, do not invoice) 3/ as demo, cancel the SO => Acccess error on res.user Problem: ======== When cancelling a subscription we want to write some fields on the partner related to the SO. If the partner is an internal user, and the current user has no access to write on res.users, we get an access error. Solution: ========= Use sudo when writing on the partner when cancelling a subscription. opw-5857627 Forward-Port-Of: odoo/enterprise#106393 Forward-Port-Of: odoo/enterprise#105901
This update resolves an issue related to the calculation of coordination deductions in the Swiss payroll module (l10n_ch_hr_payroll_elm_transmission_5_3). The fix ensures accurate reporting of these deductions, aligning with Swiss tax regulations. This improves the reliability of payroll data for Swiss businesses using Odoo Enterprise.
Original PR description
Forward-Port-Of: odoo/enterprise#106615
This update resolves an issue where the employee's filling status wasn't updating correctly when the working address state was changed. The fix adjusts the calculation of the filling status based on the address's state, ensuring accurate status reflection across the system. This prevents incorrect payroll calculations related to state-specific tax rules.
Original PR description
to reproduce: ============= - create employee and set working address with state in CA - set filling status to match the state - in the address record change the state to AL (don't change the record in employee) - go back to employee form view, filling status is still the same problem: ======== currently we are relying on a constraint to check if the filling status is valid for the state in the working address. But `api.constrains` doesn't support dotted paths, so modifying `address_id.state_id` doesn't trigger it. solution: ========= make the filling status computated field depending on `address_id.state_id` opw-5878740 Forward-Port-Of: odoo/enterprise#106511 Forward-Port-Of: odoo/enterprise#106000
This update resolves an issue where actions within the Odoo Enterprise phone system were failing when a call wasn't initially established. The change ensures that action contexts are properly set, utilizing available phone numbers to improve reliability and functionality across multiple modules like CRM, Helpdesk, and HR.
Original PR description
For sessions with a missing call, some actions were executed without a default phone number in their context. This change updates ActionList and its patches to work with the session and extract a known phone number (if any), ensuring action contexts are set correctly.
This update resolves an issue where the blackbox system wasn't sending the correct POS ID, impacting data transmission for tax reporting. A secondary change restricts blackbox device selection within the POS configuration, enhancing security and data integrity. This ensures accurate financial reporting for our SE clients.
Original PR description
When using a v1 CleanCash blackbox, the command being sent to the blackbox was mistakenly sending a POS ID of " ". It just so happened this worked correctly when testing with our blackbox because it had " " registered as a POS ID. The POS ID is now sent correctly. Another small fix was made to only allow selecting blackbox devices in the Fiscal Data Module field in the POS config settings. task-5077448 Forward-Port-Of: odoo/enterprise#106530 Forward-Port-Of: odoo/enterprise#106431
This update fixes an issue where draft and cancelled accounting entries were incorrectly included in tax return calculations, leading to inaccurate tax return amounts. Now, tax returns accurately reflect the values in related reports by excluding entries in draft or cancelled states, ensuring data integrity.
Original PR description
Behavior before: When generating tax returns, accounting entries linked to tax group accounts were included in the calculation even if they were in draft or cancelled state. As a result, tax returns…
Behavior before: When generating tax returns, accounting entries linked to tax group accounts were included in the calculation even if they were in draft or cancelled state. As a result, tax returns displayed incorrect amounts. Behavior after: Tax return amounts now correctly match the values shown in the corresponding reports. Entries in draft or cancelled state are excluded, eliminating discrepancies in tax return calculations. Root cause: The domain used in the _add_line method did not filter entries based on their parent_state. This caused all related accounting entries—regardless of their posting status—to be included in the calculation. Steps to reproduce: 1. Create accounting entries using an account that is part of a tax group. 2. Set the entries to draft or cancelled state. 3. Generate a tax return for the current period. 4. Observe that amounts from draft or cancelled entries are included in the tax return. OPW: 5417293 Forward-Port-Of: odoo/enterprise#106101
This update resolves an issue where changing a commission plan's frequency (e.g., from quarterly to monthly) didn't properly remove outdated periods, leading to incorrect commission calculations. The fix ensures that old periods are removed when the plan's frequency is updated, preventing overlapping commission targets and ensuring accurate reporting.
Original PR description
## Issue When changing the *Target Frequency* of a commission plan, previously created periods are not removed. ## Steps to reproduce 1. Install *Sale Commission* (`sale_commission`) 2. Create a…
## Issue
When changing the *Target Frequency* of a commission plan, previously created periods are not removed.
## Steps to reproduce
1. Install *Sale Commission* (`sale_commission`)
2. Create a *Commission Plan*. The default *Target Frequency* (`periodicity`) should be *Quarterly*. In the *Periods* tab, 4 periods (`targets`) are present.
3. Change the *Target Frequency* to *Monthly*
4. **New monthly periods are added, but the quarter periods are not removed**
This behavior leads to a second issue:
5. Following the previous steps, set the current user as a Salesperson the *Sales People* tab
6. Approve the Commission Plan
7. Create an invoice
- Any customer
- Add a product with a price of $100
- Confirm the invoice
8. Go to Sales > Commissions > My Commissions
9. **The invoice impacted multiple commission targets, because the current period is covered multiple times (by the monthly and the quarterly frequencies)**
## Cause
This issue was introduced by https://github.com/odoo/enterprise/commit/e7693f3c61044f689da87218235cd985e26f75d5. The commit aimed to preserve periods when updating the *Effective Period* of a commission plan. In fact, in some cases, it is unnecessary to delete all periods because some of them belong to both the previous and the updated effective period.
https://github.com/odoo/enterprise/blob/2dd98eed0559b6217ef8467f1d56c171d546b85b/sale_commission/model/commission_plan.py#L106-L108
When updating the *Target Frequency* of a commission plan, the *Effective Period* is unaffected, making the `target_changes` list empty. This leads to none of the periods being deleted, eventhough they don't respect the new periodicity.
## Fix
The condition to add periods to the `target_changes` list needs to updated, as it needs to also take in account the periodicity of the commission plan. The `expected_target_duration` needs to be a range, as it depends on the (variable) length of the months that are concerned. These ranges were chosen by looking at the sizes of each period. A margin of one day is added for the "year" case to handle leap years.
<img width="687" height="367" alt="5877405" src="https://github.com/user-attachments/assets/065b0d21-0860-4435-9f9b-55feef789da6" />
## Test
The test `test_commission_target_constraint` was using the fact that the periods were not deleted when updating the periodicity to test against the creation of overlaps between periods. As this is no longer possible, the test was updated.
opw-5877405
Forward-Port-Of: odoo/enterprise#105813This update ensures that invoices generated with the Solution Factible PAC in Mexico comply with Mexican tax regulations regarding exchange rate precision. Previously, a rounding issue caused invoices to be rejected; this fix applies the existing rounding fix to all PACs, resolving this compatibility problem and preventing invoice errors.
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. Forward-Port-Of: odoo/enterprise#105412 Forward-Port-Of: odoo/enterprise#102557
Code cleanup and technical improvements
This update simplifies and stabilizes the date filtering within Odoo's account reports. The changes enhance flexibility for fiscal year reporting and address previous issues with date range handling, ensuring more accurate and reliable report generation. The system now dynamically aligns filters with the selected date range and provides a more robust and user-friendly experience.