Monday, February 2, 2026
16 changes · 18.0
Enhancements to existing features
This update enhances the spreadsheet module by adding logging when exporting large amounts of data, specifically during spreadsheet downloads, clipboard copies, and printing. It also restricts access to downloaded frozen or XLSX spreadsheets to authorized users, improving data security and control.
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 Forward-Port-Of: odoo/odoo#210592
This update enhances the security and logging around exporting large amounts of data from Odoo spreadsheets. Specifically, it adds detailed logging for common export activities like downloading and printing, and restricts access to frozen/XLSX downloads to authorized users. This improves data tracking and protects sensitive information.
Original PR description
Forward-Port-Of: odoo/enterprise#85888
Resolved issues and error corrections
This update resolves a crash that occurred when users selected taxes within journal item dialogs on mobile. The fix replaces a problematic widget with a standard one, ensuring tax changes are saved correctly and preventing the web client from freezing. This improves stability for users entering accounting data.
Original PR description
**Steps to reproduce:** * Install the **Accounting** module. * Open a **Journal Entry** in mobile view. * Add a **Journal Item**, opening it in a form dialog. * Select a tax in the **Taxes Applied**…
**Steps to reproduce:** * Install the **Accounting** module. * Open a **Journal Entry** in mobile view. * Add a **Journal Item**, opening it in a form dialog. * Select a tax in the **Taxes Applied** field. * Click on the **Save and close** button. **Observed behavior:** * The web client crashes with `TypeError: Cannot read properties of undefined (reading 'resId')`. **Cause:** * The `autosave_many2many_tags` widget triggers `model.root.save()` immediately when a tag is selected. * When executing this save from within a transient dialog (common in mobile views), the client fails to correctly handle the record reload/synchronization leading to a crash when accessing `resId`. **Fix:** * Replace the autosave widget with the standard `many2many_tags` widget for **Journal Items** for form. * Tax changes are now kept locally in the dialog and saved only when the user explicitly saves and closes it. **Note:** * The crash happens when `autosave_many2many_tags` calls `model.root.save()` on a **new** `account.move` from within a dialog. * In QUnit tests, the mock server (`mockWebSave`) [1](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L627). which creates records [2.](https://github.com/odoo/odoo/blob/ca4d74c2a5d749ff8d41cd2fff80a73ba550a843/addons/web/static/tests/helpers/mock_server.js#L1936) in-memory and does not trigger form reloads or component destruction. * As a result, the crash cannot be reproduced in tests. opw-5497342 Forward-Port-Of: odoo/odoo#246084
This fix resolves an issue where a Sales Order Item was unexpectedly removed from a timesheet after adding a timesheet line to a helpdesk ticket. Previously, the system incorrectly cleared the Sales Order Item field. Now, the Sales Order Item from the quotation is correctly retained within the timesheet, ensuring accurate billing for timesheeted services.
Original PR description
_ ## Short functional explanation of the error Let's say a customer has made 2 sales order of 2 different serives: one service is prepaid, the other one is billed based on timesheets. When we create…
_ ## Short functional explanation of the error Let's say a customer has made 2 sales order of 2 different serives: one service is prepaid, the other one is billed based on timesheets. When we create a ticket related to this customer in the helpdesk app, the ticket automatically fills the Sales Order Item field with the prepaid service. If we remove this Sales Order Item, create a timesheet in which we set the Sales Order Item to be the timesheeted service, and press save, the Sales Order Item of the timesheet will disappear. ## Reproduction Steps 1. Create 2 products: one service based on timesheets and one service prepaid. Make sure that they create an empty project on order. 2. Create 2 quotations for the same partner: one that contains the first product you created and a second one containing the second product. Click on confirm. 3. Go to Helpdesk > Configuration > Helpdesk teams. Click on one team and under Track and Bill time, enable both Timesheets and Time Billing. 4. Create a Helpdesk ticket for the team you setup. Under customer, enter the name of the partner in the quotations. 5. Click on the ticket. The quotation related to the prepaid service should appear as the field Sales Order item on the ticket. Remove it, click on the Timesheet tab, and add a line in which, for the Sales Order Item field of the timesheet, you'd enter the quotation for the timesheeted service. 6. Hit save. ## Expected behavior The quotation entered as Sales Order Item field in the timesheet persists, while the Sales Order Item field of the ticket stays empty. ## Unexpected Behavior the Sales Order Item field in the timesheet tab disappears. ## Origin of the issue The field is_so_line_edited was kept at false as the widget used to update its value wasn't used in the view. _ opw-5384256
This update resolves an issue where users couldn't see all available Starshipit delivery services. The fix ensures Odoo sends complete order details (address, weight) to Starshipit, allowing users to select the correct and full list of services during setup. This improves the user experience and accuracy of delivery options.
Original PR description
Current behaviour: Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this…
Current behaviour: Users are unable to select certain Starshipit delivery services. Delivery methods are configured in Odoo before address or package data is available. Since Starshipit requires this data to determine availability, it returns an incomplete list during setup. Expected behaviour: Users should be able to view and select from the complete list of valid delivery services based on the actual Sales Order details (address, weight, and volume). Steps to reproduce: 1. Create new delivery method 2. Configure Starshipit API credentials. 3. Attempt to select a service. 4. Observe that not all service is shown from the available options. Cause of the issue: Starshipit filters services based on sender, receiver, and package info. Odoo requests the service list during initial configuration without this context, resulting in an incomplete list of methods. Fix: Introduce a mechanism in the Sales Order flow to add delivery methods. Send the complete shipment details (addresses, weight) to Starshipit to retrieve the accurate list of services and allow the user to select them.
This update resolves a payment error occurring when using the Avatax integration with Point of Sale. The issue stemmed from an outdated method that no longer existed, causing a crash during order settlement. The fix permanently removes this unused method, ensuring stable payment processing.
Original PR description
Step to reproduce: - configure pos for Avatax from settings - open pos and settle a order - notice a error message on payment page Cause: - error is due to usage of `replaceDataByKey` which is removed in [1] [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Fix: - we removed the method as now we do not rely on it. opw-5089351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This update addresses an issue related to how Odoo handles negative lines in EDI transactions. It backports essential functions from a recent release to ensure accurate processing of these lines, preventing potential errors and disruptions in financial reporting. This improves the reliability of our EDI integrations.
Original PR description
This PR backport helpers functions from 18.3 used to dispatch negatives lines (for EDI refusing negative lines). It also backport a fix on _split_base_line(). opw-5382423
This update resolves rounding issues that were causing Mexican EDI invoices to be rejected. The changes include adjustments to how discounts and taxes are calculated, particularly when combining multiple invoices, and using more precise numerical values to avoid discrepancies. This ensures invoices comply with Mexican regulations and can be successfully processed.
Original PR description
l10n_mx_edi* = l10n_mx_edi, l10n_mx_edi_pos, l10n_mx_edi_extended **STEP TO REPRODUCE** 1. Create a invoice with: - product price = 72.89 - discount = 10% - tax = 16% 2. Duplicate the invoice until…
l10n_mx_edi* = l10n_mx_edi, l10n_mx_edi_pos, l10n_mx_edi_extended
**STEP TO REPRODUCE**
1. Create a invoice with:
- product price = 72.89
- discount = 10%
- tax = 16%
2. Duplicate the invoice until you have 5 of them.
3. Create a global invoice with the 5 invoices, and send it.
4. The invoice will be refused by the EDI due to rounding issue.
This PR is a backport of multiples fixes done in 18.3 in which all rounding errors are fixed.
Each of them iterate upon the previous one, so they are all needed. The most important changes in thoses fixes are:
- for global invoices, deduce the discount on the base line instead of creating a 'descuento' (to avoid any problem with rounding when combining multiples invoices).
- changes in how the negative lines are dispatched.
- using raw values for 'conceptos' and 'impuestos' (5 digit precision) and changing how we compute things to solve rounding issue.
Tests files are modified accordingly, you can launch the tests with the external flag (need to be set in tests/common.py).
Backported PR (non-exhaustive):
https://github.com/odoo/enterprise/pull/92727
https://github.com/odoo/enterprise/pull/99395
https://github.com/odoo/enterprise/pull/90434
opw-5382423This update corrects a bug in the task scheduling feature where tasks were incorrectly planned with shorter durations. Specifically, when a task started on November 25, 2025, it was only scheduled for November 25-26 instead of extending into December. The fix removes previously used scheduling intervals to ensure accurate hour allocation.
Original PR description
Steps to Reproduce: 1- Auto-plan a task starting on 25 November 2025 with 40 allocated hours. 2- The computed end date becomes 26 November, instead of extending into early December. => As a result, the allocated period is shorter than the required hours. Source: When selecting 25/11/2025 as the start date, the system tries to schedule the task within the remaining days of November (25–28). However, these four days are not enough to cover 40 hours. The system then searches for available intervals in the next month. But the intervals from November are still kept in the list, so when the algorithm iterates again, it reuses the previously consumed intervals (25 and 26). This causes the scheduler to allocate the remaining hours to those same days, leading to an incorrect result where the task spans only 25–26 November, instead of continuing from 1 December. Solution: Remove already-used intervals before recomputing the schedule. opw-5364327
This update fixes a translation issue where warnings on Swiss payroll slips didn't display translated field names. The change ensures that all warning messages are correctly translated into French (CH), improving the user experience for French-speaking Swiss users. This resolves a reported bug impacting data accuracy and usability.
Original PR description
The warnings that appear on a payslip when the employee's form misses information are not fully translated Steps to reproduce: 1. Install module l10n_ch_hr_payroll 2. Switch to "My Swiss Company" and change language to French (CH) 3. Open app "Paie" and create a new employee (only add a name) 4. Click on "Contrats" in the stat button and create a new contract for the employee (only add a name), save it and set it as "En cours" in the status bar 5. Go to "Fiches de paie" > "Toutes les fiches de paie" and create a new payslip 6. Add the newly created employee to the payslip 7. The warnings in the form displaying the missing fields from the employee form do not translate the name of the missing fields Solution: Use `get_description` to get the translated name of the missing fields opw-5403634 Forward-Port-Of: odoo/enterprise#104499
This pull request reverts a recent change that caused public holidays to not display correctly on work schedules without a company assigned. This resulted in time off requests including incorrect holiday durations. The fix is being reverted to allow for a more targeted resolution of the underlying issue in the project module, minimizing impact on HR and Resource modules.
Original PR description
Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8 **Steps to reproduce** 1.…
Revert of https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 and
https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
**Steps to reproduce**
1. Remove the company of the Working Schedule (needs to be done in
a multi-company environment from the UI) used by an employee.
2. Using the company of this employee, create a Public Holiday
(for the employee's schedule or all schedules).
Issues:
- the public holiday doesn't appear in the Time Off dashboard
- when taking a time off on that day, the public holiday is
included in the duration
**Cause**
After the fix in https://github.com/odoo/odoo/commit/a95af8b78a94a795e05a0adf299837adc0ef2117 , it will lead
to a search domain for public holidays of `('company_id', 'in', [False])`
when the working schedule has no company, ignoring any public
holidays with a company set. This is especially problematic since the
company of the public holiday is always forced.
https://github.com/odoo/odoo/blob/7bce5f3f95429a4d4ba034a66c350ee2a5868567/addons/resource/models/resource_calendar_leaves.py#L49-L51
**Solution**
Since the intent of the original fix https://github.com/odoo/odoo/commit/f4f9ecb3e4801b3d382abc24c478fe5e533c9bf8
was to correct an issue related to the computation of some `project.task`
fields calling a resource method (`get_work_duration_data`), we can revert
the fix and later fix the original issue directly in `project`, without
impacting `hr`/`resource` modules.
opw-5496999
opw-5401425This update fixes an issue where subscription invoices were being generated prematurely when a note or section was added to the subscription. The fix ensures that invoice dates align with the expected end-of-period billing, regardless of whether a note is present. This improves invoice accuracy and consistency for our subscription customers.
Original PR description
**Steps to reproduce** - Have a subscription service product with invoicing policy set to "Based on delivered quantity (manual)". - Create a new monhtly subscription with this product and add a section or a note. - Confirm the subscription. Actual: next invoice date is today. Expected: same as without section/note, next invoice date should be at end of the period. **Cause** `_is_postpaid_line` should only be called on actual product lines. Related: https://github.com/odoo/enterprise/commit/d8a7f7cc2d9d11e42ed24db1b0f7a3c08c7fac1c opw-5478394
This update resolves an issue preventing single-tenant Odoo apps using Microsoft Calendar from properly renewing their access tokens. The fix ensures Odoo uses the correct, tenant-specific Microsoft endpoint, allowing for reliable calendar synchronization with Outlook. This improves functionality for businesses utilizing single-tenant Azure environments.
Original PR description
Single-tenant Azure applications could synchronize calendar with Outlook, but refresh token renewal fail. Odoo was always using the default Microsoft token endpoint instead of the tenant-specific endpoint required for single-tenant apps. Steps to reproduce: - Create a single-tenant app in the Azure portal - Configure Odoo Microsoft Calendar with this app - Set `microsoft_account.auth_endpoint` and `microsoft_account.token_endpoint` system parameters with the specific endpoints using the tenant ID - Open the Calendar app and sync with Outlook - Wait for access token expiration - Refresh token request fails This commit fixes the issue by using the token endpoint stored in the microsoft_account.token_endpoint system parameter when requesting a refresh token. Forward-Port-Of: odoo/odoo#244371
This update resolves a problem where EU VAT numbers were not being saved correctly during address updates in the Odoo portal. The fix corrects a conversion process that was causing validation errors. This ensures accurate VAT handling for European customers.
Original PR description
### Issue: EU vat fix cause address submission to fail. #### Steps to reproduce: 1- `base_vat` should be installed. 2- In portal contact, set the country to BE and VAT to `0477472701`. 3- Create an invoice for portal user. 4- Navigate to shop and add a product to cart, then checkout. 5- Edit address. 6- After filling, click on save address. Even though the VAT is not modified in form, and it is not modifiable the address fails to save with error: `Changing VAT Number is not allowed.` ### Cause: After address submission The vat is fixed in here: https://github.com/odoo/odoo/blob/82a2c5305d65027ffb263f90c4e00f7e95f98b05/addons/website_sale/controllers/main.py#L1396-L1406 This converts given vat `0477472701` to `BE0477472701`. Which makes `address_values['vat'] != partner_sudo.vat`: https://github.com/odoo/odoo/blob/82a2c5305d65027ffb263f90c4e00f7e95f98b05/addons/website_sale/controllers/main.py#L1472-L1482 opw-5437586
This update fixes a potential issue in the restaurant booking process. The system now waits for the order to fully synchronize with the floor screen before confirming its status. This prevents errors related to checking for the loader or server ID prematurely, ensuring bookings are processed correctly and reliably.
Original PR description
When booking the table we now wait to be back on the floor screen before checking that the loader is gone and that the order has a server ID. If we don't do that we might check that the loader is not there before it appears, and then checking the server ID before it is set. runbot-227652
This update resolves an issue where customers using self-service invoicing through Peppol received duplicate invoices repeatedly. The root cause was a technical glitch in how Odoo handled invoice creation and API calls, leading to unnecessary transmissions. This fix ensures invoices are sent only once, improving efficiency and accuracy for Peppol customers.
Original PR description
Steps to reproduce: - Set up a test company with Peppol enabled - Create a Peppol customer and ensure they can receive invoices - In the POS settings, enable the “Self-service invoicing” option - Create a POS order linked to the Peppol customer - Log in as this customer - Enter the POS order information to access the invoice download view (from /pos/ticket) - Repeatedly click the “Request invoice” button - On the Peppol side, you will notice that the same invoice is sent as many times as the button is clicked Why ? This error is not really Peppol related, it can actually happen with all EDI making API call: the transaction is rolled-back when Odoo tries to create multiple invoices with a serialization error but the API call happened so, in this cas, the invoice is sent over Peppol. opw-5469467