Tuesday, October 21, 2025
28 changes · 19.0
Enhancements to existing features
Point of Sale payment terminals connected through IoT can now use newer connection methods in addition to the existing fallback. This improves communication flexibility and can help make terminal interactions more reliable across different network setups.
Original PR description
As for any other actions sent from the db to the IoT Box, we updated payments terminals logic to use the `iot_http` service in order to allow them using webrtc and websocket in addition to longpolling. Backport of odoo/enterprise#92896 (`iot_http` service refactoring only, to allow listening without sending action) Backport of odoo/enterprise#96634 odoo/odoo#232282 Forward-Port-Of: odoo/enterprise#97617
The website editor now detects when a browser or device cannot support WebGL and disables image filters instead of showing an error. This keeps editing stable for users on affected Linux Chrome versions or systems without usable graphics support, while clearly indicating why image filters are unavailable.
Original PR description
On recent versions of Chrome for Linux (v140+), the old SwiftShader software fallback for WebGL has been removed. As a result, new window.WebGLImageFilter() now throws if no GPU context is available, typically when WebGL is disabled or unsupported. Since the application cannot enable WebGL from JavaScript, this commit improves the user experience by detecting the absence of a WebGL context early and disabling image filters in edit mode. Instead of raising a traceback, the editor now skips the filter feature and can optionally display a friendly message explaining that WebGL is required to use image filters. This avoids runtime errors and ensures a more robust behavior on platforms where WebGL is unavailable. task-5117584 Forward-Port-Of: odoo/odoo#232009 Forward-Port-Of: odoo/odoo#229705
Manufacturing planning now calculates monthly product demand using the exact date range being analyzed instead of a broad preset label. This makes forecasts slightly more precise and consistent with the stock movements included, while related field service catalog code was cleaned up for better maintainability.
Original PR description
Changes the context keys used in the compute of product.product monthly demand from a string "suggest_based_on" to 2 datetime objects, the start and end date from which to consider moves. see odoo/odoo#225721 Some values from the test are changed (also some relevant changes in this previous commmit odoo/odoo#0a022c0777). The discrepencies are due to change of factor logic from if based_on == "three_months": factor = 3 to factor = (limit_date - start_date).days / (365.25 / 12) or 1 --> For example turning a based on 3 months monthly demand with 30 products sold 2 months ago will change from BEFORE: 30 / 3 = 10 NOW: 30 / (92 / (365.25 / 12)) = 9.92 Using start_date = now() - relativedelta(months=3) means (limit_date - start_date).days can range from 89-92 days depending on the month. But this makes sense as the daterange used to select moves that go in the monthly demand calc will be based on the same number of days. task#4783508
Documentation courses can now receive reviews, just like training courses, helping organizations collect feedback on a wider range of learning content. Comments are turned off by default for documentation courses to better match their less interactive nature, and course type guidance is clearer with a new tooltip.
Original PR description
Only "training" course were allowed to be reviewed. We extend it here to all type of course (i.e. also "documentation" course). As documentation courses are less "participative", we disable comment by default for those courses. We also add a tooltip for course type field. Task-4568069
Updates Uruguay localization to recognize reduced VAT rates beyond the standard exempt, minimum, and basic categories. This helps businesses produce compliant electronic invoice XML and tax reports for eligible card or electronic-money sales.
Original PR description
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and…
To fully comply with regulatory requirements, we need to support an additional category called "Reduced Tax Rate" when a product line has a Reduced VAT rate (e.g., 20%) for sales of goods and services to final consumers when payment is made by debit card or electronic money instrument (and other specific reductions in similar cases).
1. Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2. Modifying XML Output:
* In the <Totales> section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the <MntIVAOtra> tag.
* Example: xml <MntIVAOtra>140</MntIVAOtra> (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the <IndFact> tag to 4: xml <IndFact>4</IndFact>
*Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3. Tax Grid for Configuration:
*Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232132
Forward-Port-Of: odoo/odoo#221073Uruguayan electronic invoices can now correctly handle VAT rates outside the standard exempt, minimum, and basic rates. This improves tax reporting accuracy by including reduced-rate VAT in the official XML invoice totals and making the related tax grid available for configuration.
Original PR description
1) Detecting "Reduced Tax Rate": * Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced…
1) Detecting "Reduced Tax Rate":
* Identify product lines with a VAT rate that is neither 0% (exempt), 10% (minimum), nor 22% (basic). Any VAT rate outside these three should be considered "Reduced Tax Rate".
2) Modifying XML Output:
* In the `<Totales>` section of the XML, include the total amount of VAT under the "Reduced Tax Rate" in the `<MntIVAOtra>` tag.
* Example: ```xml <MntIVAOtra>140</MntIVAOtra> ``` (where 140 corresponds to the VAT calculated at the reduced tax rate, e.g., 20%).
* For each product line using "Reduced Tax Rate," set the `<IndFact>` tag to `4`: ```xml <IndFact>4</IndFact> ```
* Ensure the total amount reflects the base amount plus the VAT under "Reduced Tax Rate".
3) Tax Grid for Configuration:
* Add a new tax grid called Sales Reduced VAT to be used for the tax configuration of the "Reduced Tax Rate."
* This will ensure proper reporting and consistency in tax declarations.
* The new tax grid should be selectable when configuring other taxes.
Odoo Implementation Considerations:
* The tax computation logic in Odoo already supports defining taxes at different rates.
* Adapt the XML generation logic to check for product lines with a non-standard VAT rate and apply the necessary modifications. Ensure the final totals in the XML align with Odoo's computed tax amounts.
Task latam side: 1330
Task Adhoc side: 52999
Forward-Port-Of: odoo/enterprise#97521
Forward-Port-Of: odoo/enterprise#91392Resolved issues and error corrections
This update lets Odoo process files before they are uploaded, including resizing image files when needed. This helps keep uploaded Studio icons and similar images from unnecessarily increasing database size.
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#231899 Forward-Port-Of: odoo/odoo#226611
Tax return creation now correctly recognizes fiscal years that do not start in January. This prevents incorrect “wrong dates” warnings when users create annual returns aligned with their company’s configured fiscal year.
Original PR description
When the company fiscal year is not the first of the year (Aug 1 → Jul 31), creating a tax return for the fiscal year (2024-08-01 → 2025-07-31) wrongly triggers the wizard’s “wrong dates” warning.…
When the company fiscal year is not the first of the year (Aug 1 → Jul 31), creating a tax return for the fiscal year (2024-08-01 → 2025-07-31) wrongly triggers the wizard’s “wrong dates” warning. The wizard validates the range by slicing it into periods via `_get_period_boundaries()`, which anchors the first period using `_get_start_date_elements()`. If we dont have `deadline_start_date` that anchor falls back to a fixed Jan 1 (calendar year) instead of the company’s fiscal-year start. Consequently, the first computed period becomes 2024-01-01, so the check sees a mismatch and flags the warning even though the user’s dates are perfectly aligned with the fiscal year. The fix is to use the company’s fiscal-year start as the anchor for period slicing instead of silently defaulting to Jan 1. `_get_start_date_elements()` still prefers the explicit `deadline_start_date` (unchanged behavior for calendar-anchored VAT returns), and otherwise derives the day/month from `company.compute_fiscalyear_dates(today)['date_from']`. Steps to reproduce: Accounting: Settings and set Fiscal Year End to July 31 Reporting: tax reports and set it to Year and the year to 2024 Top left there is the Return, click on it and set: - Opening Date: 08/01/2025 - Fiscal Year End: 31 July - VAT Periodicity: Annually Creat a new tax return and chose any type and set: - start date 08/01/2024 - end date 07/31/2025 opw-4990676 Forward-Port-Of: odoo/enterprise#94325
Partial payments made from the invoice payment widget will no longer trigger an automatic write-off just because the remaining amount is within tolerance. Invoices now stay marked as partially paid until the remaining balance is intentionally handled, helping users keep more accurate payment status and control.
Original PR description
Prevents the system from creating a write-off and marking an invoice as 'Fully Paid' when a partial payment (within tolerance) is reconciled from the invoice form. The invoice status will now correctly remain 'Partially Paid', giving the user control over the remaining balance. task-5114658 Forward-Port-Of: odoo/enterprise#95899
Mobile self-order customers now see the correct order after placing a new order, instead of being shown a previous paid order. Receipts downloaded after refreshing the page also keep their payment details, preventing confusing missing payment or negative change lines.
Original PR description
This PR contains 2 small fixes for mobile self order: - **[FIX] pos_self_order: wrong order on confirmation screen** Steps to reproduce: 1. Configure a Self Order POS to use QR menu + ordering 2. In…
This PR contains 2 small fixes for mobile self order:
- **[FIX] pos_self_order: wrong order on confirmation screen**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. In the mobile menu, make an order and confirm
3. The confirmation screen shows order S001, pay at the counter
4. In the POS, pay and validate the order
5. In the mobile menu, make another order and confirm
Expected behaviour:
- The confirmation screen shows order S002, pay at the counter
Actual behaviour:
- The confirmation screen shows order S001, already paid
The cause of this is that `selectedOrderUuid` is cleared whenever the
`getUserDataFromServer` method is called, even if the server doesn't
return an order to replace it with. The self order service then tries
to find the current order and takes the previously paid order instead of
the new order.
To fix this, we simply don't clear `selectedOrderUuid`. It will still be
overwritten if the server does return new order data.
- **[FIX] pos_self_order: incorrect receipt after refresh**
Steps to reproduce:
1. Configure a Self Order POS to use QR menu + ordering
2. Make an order in the mobile menu
3. Pay and validate the order in the POS using the 'Card' payment method
4. Go to 'My Orders' in the mobile menu, and download the receipt
5. Observe the correct 'Card' payment line is shown on the receipt
6. Refresh the page
7. Download the receipt again
Expected behaviour:
- The downloaded receipt is the same as the first one, with the 'Card'
payment line.
Actual behaviour:
- The downloaded receipt has no payment lines, so it just shows a
negative 'Change' line at the end.
The cause of this issue is that the payment lines and payment methods
used to render the receipt were not being persisted in the indexed DB.
The fix is simply to add these models to the data service options so
that they also get saved locally.
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#232314
Forward-Port-Of: odoo/odoo#231910Fixed an issue where saved payment methods were not offered when registering payment on a later invoice for the same user. The payment process now uses the invoice's linked customer rather than the company contact, helping payments be completed without manual workarounds.
Original PR description
Currently, when user A from company AA records a payment method, a payment token is stored for that user. However, when an invoice is issued for that user, the payment token cannot be used because the payment registration form uses the partner AA instead of the user linked to the move, partner A. Step to reproduce: 1. Create a user A in company AA 2. Create an invoice for user A 3. Register a payment on the invoice and save the payment method (token) 4. Create another invoice for user A 5. Try to register a payment on the invoice: the payment token is not proposed This fix updates the logic to use the user linked to the move instead of the partner on the line, allowing proper selection of a payment token. opw-5036106 Forward-Port-Of: odoo/odoo#232134 Forward-Port-Of: odoo/odoo#230105
Point of Sale now applies minimum-quantity pricelist rules based on the total quantity of the same lot-tracked product, even when items are split across multiple lots. This ensures customers receive the correct price or discount at checkout and avoids undercharging or overcharging caused by separate lot lines.
Original PR description
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot…
**PROBLEM** Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should). **STEP TO REPRODUCE** 1. install pos 2. create a lot tracked product 3. create a pricelist rule for the product, with a price based on min qty 4. from the pos, order the min qty but split it accross multiple lots 5. price will not takethe rule into account **CAUSE** Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually. **FIX** For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked. **REMARK** Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db. opw-4751920 Forward-Port-Of: odoo/odoo#232276 Forward-Port-Of: odoo/odoo#219110
This update fixes multiple small issues affecting website content, Indian e-Waybill printing, payments, mail cleanup, SMS validation, and IoT certificate handling. It improves day-to-day reliability by preventing printing failures, stale activity records, unnecessary certificate requests, and regressions in website sitemap language behavior.
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 fixes an issue where Swiss payroll pay run generation could fail or be blocked when users worked across multiple companies. It helps payroll teams generate pay runs reliably in multi-company setups without unnecessary access problems.
Original PR description
Forward-Port-Of: odoo/enterprise#97503
Vendor bill XML imports for Ecuador now correctly include discounts when a discount value is present in the file. This prevents understated discounts and helps keep imported supplier bills aligned with the original invoice totals.
Original PR description
In the l10n_ec_edi localization, XML files that include a <descuento> (discount) tag do not apply the discount when imported into Odoo. - Create an invoice with a discount and export the XML. - Re-import the XML as a vendor bill — the discount is missing. This commit fixes the issue by computing and importing the discount percentage from the <descuento> tag. opw-5137439 Forward-Port-Of: odoo/enterprise#96712
The Planning and Timesheet Analysis report now calculates planned and remaining hours using each employee's own working schedule rather than assuming a standard Monday-to-Friday week. This gives managers more reliable capacity and workload figures for employees with part-time or non-standard calendars.
Original PR description
To reproduce: ============= - set the company calendar to 40h/week (Mon to Fri) - create an employee with a 32h/week working schedule (doesn't work on Fri) - on planning app, create a shift for this employee for ex from 01/09 to 15/09 with 2h allocated - go to Planning / Timesheet Analysis report and check report for this employee on september -> planned hours and remaining hours are wrong Problem: ======== when querying the data for the desired period, we divide the allocated hours by the number of weekdays (Mon to Fri) in the period, but we should divide by the number of working days according to the employee's working schedule Solution: ========= we compute the number of working days based on the resource calendar of the employee and use this number to compute the planned hours and remaining hours opw-5008066 Forward-Port-Of: odoo/enterprise#95115
This fixes a Belgian SEPA payment file issue where a required payment reference field could be left empty. The change helps banks process generated payment files correctly and reduces failed or rejected payment batches.
Original PR description
The XML of the spea file in format pain.001.001.03 in l10n_be has a missing EndToEndId tag. - Configure the bank to use the pain.001.001.03 sepa xml format. - Generate a payment using sepa. Create a batch for this payment and validate. - The resulting xml has an empty EndToEndId tag. Commit fa08eac141956141bc12c1d5619bd57f487c36e9 responsible - investigate opw-5150525
This fixes an error that could prevent users from opening Timesheets and Planning Analysis from a project. The change makes the report handle missing currency information safely, improving reliability for teams using timesheet forecasting and sales planning.
Original PR description
### Issue: A traceback occurs when opening Timesheets and Planning Analysis. #### Steps to reproduce: 1. Create a database with `project_timesheet_forecast_sale` installed. 2. Create a project and open the three-dot menu. 3. Click on `Timesheets and Planning Analysis`. ### Cause: The error occurs because `currencyIds` is undefined. This issue was introduced by #224667. ### Solution: Add a safe access check for `currencyIds`. opw-5176269
This fix restores the default cash journal when setting up companies using the Turkey and Jordan accounting localizations. It helps those companies meet local compliance requirements after the journal was previously removed during an accounting interface cleanup.
Original PR description
This commits adds back default cash journal for companies intializing with l10n_tr and l10n_jr. In our efforts to cleaning the UX/UI of accounting (PR #192031 task-4430969) We removed the default cash journal, however, some locatizations, such as l10n_tr and l10n_jo, require them for compliance reasons task-4991218 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#232113 Forward-Port-Of: odoo/odoo#231200
Manual AI-triggered actions now carry the needed record context, so follow-up actions like creating records, scheduling activities, or sending emails actually run. The AI document sorting setup is also easier to use because related tools can be opened directly and new actions are AI-ready by default.
Original PR description
Purpose: -------- Currently, when an AI server action is triggered manually, the child server actions with state != code are not executed. Nothing happens because inside `_run`, the server action is executed on each record obtained by browsing the ids given by the `active_ids` and `active_id` keys in the context, which are not present (it works fine when the action is triggered by an automation because the record info is added in the context in `_process` in base automation). This commits adds the current records info in the context of the ai tools so that these server actions (such as create record, create activity or send mail) are now executed). Task-5107876
This fixes an issue where businesses running multiple websites could see pages from the previously visited website after switching to another one. The website now uses the right cache separation so each site shows its own correct content, reducing confusion for visitors and editors.
Original PR description
After this [commit], we had an issue when we had multiple websites and tried to switch from one of them to another, the cached page of the previous one would still be present. task-5152918 [commit]: https://github.com/odoo/odoo/commit/6c8a90ecba45fb99addf1b86fe237fd626fba650
Odoo now blocks account report formulas that accidentally leave an empty account code prefix, which could otherwise include all accounts and duplicate amounts. It also catches invalid aggregation formulas when reports are created or edited, helping businesses avoid misleading financial reports.
Original PR description
Empty account code prefixes in report expressions (e.g., "12 + 13 +") unintentionally include all accounts, which can lead to duplicated amounts. This PR raises a UserError when a newly created or modified expression includes an empty prefix. task-id: 4975559
Point of Sale can now create receipt and payment QR codes directly in the browser instead of relying on the server. This helps stores print receipts with QR codes even when the POS is offline and keeps receipt layouts more reliable.
Original PR description
Import the `qrcode` JS library and render QR codes directly in the browser instead of requesting them from the backend. This allows receipts with QR codes to be generated and printed even when the POS is offline. Problem was that we cannot use `ZXing.BrowserQRCodeSvgWriter();` (which is a library already used in the POS that can generate QR code) because it generates an unpredictable padding, which cause some issues in the receipt layout. task-id: 5060246 task-id: 5060246 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#228242
Account report formulas now reject newly created or edited entries that leave an account code prefix blank. This prevents reports from accidentally including all accounts and duplicating amounts, improving financial report accuracy.
Original PR description
Empty account code prefixes in report expressions (e.g., "12 + 13 +") unintentionally include all accounts, which can lead to duplicated amounts. This PR raises a UserError when a newly created or modified expression includes an empty prefix. Community and main part of the PR: https://github.com/odoo/odoo/pull/230302 task-id: 4975559
This update prevents reconciliation failures when custom settings change the default type for journal entries. Write-offs created by the reconciliation wizard are now always treated as standard journal entries, avoiding errors about missing partners or incompatible account types.
Original PR description
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account…
Behavior before commit: On certain configurations, attempting to reconcile a Journal Item through the wizard caused an exception to be thrown due to either a missing `partner_id` or incorrect account type. Root cause: The wizard used the default `move_type`. While this is usually `entry`, a customisation can change it. Since types other than `entry` have more robust requirements in terms of necessary fields (ie. `partner_id`) and account type limitations, this results in an exception being raised. Fix: Added a line in `write_off_vals` that explicitly assigns `move_type` as `entry`. Steps to reproduce: 1. Have unreconciled Journal Items. 2. Define a new User-defined default for the Journal Entry model, setting its default type to a value other than "Journal Entry". 3. Select an unreconciled Journal Item in the list view and attempt to reconcile it through the wizard. 4. Observe the exception pointing to a missing `partner_id` or incorrect account type. opw-5107155 Forward-Port-Of: odoo/enterprise#97130 Forward-Port-Of: odoo/enterprise#97028