Friday, September 26, 2025
21 changes · saas-18.2
Resolved issues and error corrections
The purchase form print button now selects the right document based on the order status. Draft and sent requests print an RFQ, while confirmed or locked purchases print the purchase order, reducing customer confusion and manual workarounds.
Original PR description
Why : -------------- in saas~18.2 version the option of 'print' on purchase form view was introduced in smart button. https://github.com/odoo/odoo/pull/197211 Before fix : ---------------- The print button in the purchase form view prints only RFQ no matter on which stage the PO is. After fix : ---------------- in RFQ and RFQ sent stage the print button will print RFQ report in Purchase order or Done(Lock) state print button will print purchase order report Steps to regenerate: ------------- - Create an Request for quotation - Confirm the Request for quotation - Print report when in purchase/Lock state using print smart button OPW: 5060711 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix prevents cashiers from repeatedly pressing Validate while an online POS payment is still syncing. It avoids payment validation errors on slow networks, helping checkout continue more reliably.
Original PR description
Currently, an error occurs when validating an online payment if the network is slow. **Steps to Reproduce:** 1) Install POS (with demo data) and the Demo Payment module. 2) Go to Payment Methods and…
Currently, an error occurs when validating an online payment if the network is slow.
**Steps to Reproduce:**
1) Install POS (with demo data) and the Demo Payment module.
2) Go to Payment Methods and create a new online payment method for any shop (e.g., a clothing shop). Set the Payment Provider to `Demo`.
3) Open a POS session for the clothing shop, select any product, and proceed to payment.
4) Open Inspect → Network tab, create a custom slow network profile(e.g., `set both download and upload speed to 1 KB/s`), and switch to that network.
5) Select the online payment method you just created and continuously click on Validate.
Error:
ValueError: Expected singleton: pos.order('p', 'o', 's', '.', 'o', 'r', 'd', 'e', 'r', '_', '4')
**Root Cause:**
When an online payment is validated, the `_isOrderValid` and `addNewPaymentLine` methods are called.
- With a slow network, the order ID is still temporary(e.g., e74a3369-7dcd-4234-b35e-04daa149ffe6) as the order is not synced completely, when the code at [1] is executed.
- Due to multiple clicks, `_isOrderValid` forces a call to `update_online_payments_data_with_server` at [2] before order is synced.
- This eventually passes the temporary ID to `get_and_set_online_payments_data` at [3], causing the issue.
**Fix:**
Prevent multiple clicks on Validate until the order is successfully synced.
[1]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L11-L17
[2]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/components/payment_screen/payment_screen.js#L87
[3]- https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/pos_online_payment/static/src/overrides/pos_overrides/models/pos_store.js#L18-L26
**sentry-6849786792**
Forward-Port-Of: odoo/odoo#225371The website shop sitemap now avoids loading too much product data at once when catalogs are very large. This helps prevent server crashes caused by search engine crawlers requesting the sitemap, improving reliability for ecommerce websites.
Original PR description
### Issue Server crashes with MemoryErrors when a database has a large product catalogs. ### Solution This commit disables the prefetcher to avoid MemoryErrors when generating the sitemap for large product catalogs as web crawlers would continously crash the server when requesting the sitemap. ### References opw-5001680 opw-4955333 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#223054
Point of Sale now prevents two users or sessions from creating separate invoices for the same order at the same time. If invoicing is already underway, users see an error, and if an invoice already exists, the system opens it instead of creating a duplicate.
Original PR description
This fix prevents multiple users from generating separate invoices for the same POS order simultaneously. Steps to reproduce: 1. Create a new POS order. 2. Open two tabs (or two POS sessions). 3. Generate an invoice in the first tab. 4. Immediately try to generate an invoice in the second tab. 5. Two invoices will be generated. With this fix: - If a user attempts to generate an invoice while another is already in progress, an error message is shown. - If the invoice has already been generated, the existing invoice view is opened instead of creating a duplicate. opw-5004504
This fix prepares Danish NemHandel partner information during module installation instead of calculating it later during updates. This helps reduce long update times and makes deployments smoother for businesses using Danish e-invoicing.
Original PR description
To avoid lengthy update due to the compute of the records by the ORM, let's pre-compute the nemhandel fields on the install of the module. 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#228102
Self-order and kiosk orders using online payment are now shown on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring confirmed orders reach the kitchen even when customers leave through the payment portal exit flow.
Original PR description
pos_*= pos_online_payment, pos_online_payment_self_order, pos_self_order Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Enterprise PR: https://github.com/odoo/enterprise/pull/95312 Backport of https://github.com/odoo/odoo/pull/213493, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
When shoppers add either a kit product or one of its components to their cart, the online store now updates the shown availability for related products that share the same stock. This helps prevent customers from seeing stale stock quantities or ordering items that are no longer available through a kit/component relationship.
Original PR description
### Steps to reproduce: - In the settings website > Shop: - Disable `Out-of-Stock: Continue Selling`. - Enable `Show Available Qty` if below 5 units. - Create 2 storable products published on the…
### Steps to reproduce:
- In the settings website > Shop:
- Disable `Out-of-Stock: Continue Selling`.
- Enable `Show Available Qty` if below 5 units.
- Create 2 storable products published on the website:
- COMP, put 1 unit in stock.
- KIT with bom of type Kit using 1 x COMP.
- With a private window go to the shop.
- Add 1 x COMP or KIT to the chart.
#### > This is not reflected on the available quantity in stock of the other product
### Cause of the issue:
The availability on the website is computed from the product availability using the `free_qty` fetched because of this override: https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/controllers/variant.py#L10-L13 from which the cart quantity of the product itself is deduced before re-render:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L49-L51 https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/website_sale_stock/static/src/js/variant_mixin.js#L83-L86 While the `free_qty` is correctly computed from kit products based on the component availability:
https://github.com/odoo/odoo/blob/d358542c9159f325b4e2ff184ed1f5cdb6b8c5a9/addons/mrp/models/product.py#L211-L221 The qties in the virtual cart quantities are not recomputed base on kits.
opw-4889956
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#228369
Forward-Port-Of: odoo/odoo#222945This fixes a stock transfer issue where validating a delivery with no actual quantities to process could open a backorder prompt that did nothing. Users now receive a clear error instead, preventing confusion and avoiding meaningless follow-up actions.
Original PR description
### Steps to reproduce: - Create and confirm a delivery with 2 moves: - 1 x product 1 - 1 x product 2 - Set the quantity of product 2 to 0 and mark it as picked - Validate the transfer #### > The…
### Steps to reproduce:
- Create and confirm a delivery with 2 moves:
- 1 x product 1
- 1 x product 2
- Set the quantity of product 2 to 0 and mark it as picked
- Validate the transfer
#### > The backorder wizard open's even though there is nothing to validate. Creating a backorder does nothing.
#### Cause of the issue:
Since there is a picked move, the picking validation does not pick every moves in the `pre_action_done` hook keeping only moves with empty qty as picked:
https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_picking.py#L1208-L1209 Then, only the picked moves are processed in there `_action_done`: https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1914 https://github.com/odoo/odoo/blob/9b41eb38403e64091b74e1ae53c79488aa48b499/addons/stock/models/stock_move.py#L1929-L1937 Which leads to an empty picking validation.
opw-5076640
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#227995Point of Sale now shows only the quotations and orders linked to the customer selected by the cashier. This prevents staff from seeing unrelated customer orders and helps them find the right sale faster.
Original PR description
Before this commit, when selecting a customer in the POS and clicking Actions → Quotation/Order, all quotations and orders were displayed instead of filtering by the selected customer. This commit ensures that only the quotations/orders of the selected customer are shown. opw-5074052 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227448
This fix prevents older untranslated-but-existing field translations from being deleted during upgrades. Businesses upgrading Odoo can keep those translation records available for recovery instead of unexpectedly seeing previously translated content revert to English.
Original PR description
After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you will notice that some fields that were translated before, are now in English. This is likely because those translations were…
After upgrading Odoo from earlier versions to versions >= Odoo 15.5, you will notice that some fields that were translated before, are now in English. This is likely because those translations were not marked as `state='translated'` in the DB. However, the missing translations were removed from the `_ir_translation` table during the upgrade. With this patch, we still keep the conservative behavior of only auto-translating fields marked as `state='translated'` in the DB (which is still probably wrong, because user translations should remain the same; if Odoo was displaying translated text before the upgrade and it is not after it, that's probably a bug; but that's another story...), but we no longer delete the other fields. This way, you can still mark them as translated after the upgrade and use the new tooling provided in https://github.com/odoo/upgrade-util/commit/fd578e31973596bf7f283ea5c6ebbdfd3314f8bc to recover those translations after the upgrade. @moduon MT-11570 cc @aj-fuentes Forward-Port-Of: odoo/odoo#228404
This fixes an issue where earlier manufacturing operations could incorrectly change from cancelled to in progress after a later backordered operation was completed. The correction helps production teams see accurate work order statuses and avoid confusion when tracking partially completed manufacturing orders.
Original PR description
In this bug, in backorder created for later work opertions, the `state` of initial operation is changed to `progress` after, the backorder is `done`. To produce the bug: 1- Create a Bill of Materials with at least two operations at two work centers 2- Create a manufacturing order and confirm it. 3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity 4- In the second work order, the first operation initially appears as `Cancelled`. Once the second operation is completed, it will change to `In progress`. opw-4931653 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#222075
Invoice analysis now shows accurate product quantities, average prices, margins, and inventory values when invoice lines use product packaging. This prevents misleading sales and profitability reporting caused by outdated unit conversion formulas after the unit-of-measure system change.
Original PR description
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost,…
#### Issue: Quantity, average price, margin and inventory value are wrong in Invoice analysis for invoice lines using packagings. #### Step to reproduce: - Choose a product - Make sure it has a cost, and it differs from sales price - In the sales sheet, add a packaging - Create a sale order - Add the product using the package - Confirm - Go to delivery, validate - Back to sale order create an invoice and confirm it - Go to "Invoice Analysis" - Go to Pivot View - In "Measures" select: - Average Price, - Inventory Value, - Margin, - Product Quantity - In "Total" select: - Product #### Current behavior: - Those fields display wrong values as they were miscalculated: - Average Price line_balance / number_of_packages * number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages / number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages / number_of_unit_in_package - Product Quantity number_of_packages / number_of_unit_in_package #### Expected behavior: - These fields should be right: - Average Price line_balance / number_of_packages / number_of_unit_in_package - Inventory Values account_currency_table.rate * number_of_packages * number_of_unit_in_package - Margin margin_on_one_unit * number_of_packages * number_of_unit_in_package - Product Quantity number_of_packages * number_of_unit_in_package #### Cause of the issue: - As per the refactor of the UoM and packaging, the uom factor field is now the mathematical inverse of the previous uom factor field. This model wasn't updated and used wrong formulas. opw-5031495 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Bill Matching now treats individual vendor contacts and their parent company consistently when matching purchase orders with vendor bills. This prevents an error that could block users from completing bill matching in purchasing workflows.
Original PR description
**Issue** When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback. **Steps to Reproduce** 1. Create an…
**Issue** When both a Purchase Order and a Vendor Bill are created using the same individual contact linked to a company, Bill Matching fails with a traceback. **Steps to Reproduce** 1. Create an individual contact and link it to a company. 2. Create a Purchase Order with the individual as a vendor. 3. Create a Vendor Bill with the same individual as the vendor. 4. Try to perform Bill Matching. 5. A `ValueError: Expected singleton: res.partner(...)` is raised. Video for reference: https://drive.google.com/file/d/1qVnPLpk8jyMTKz-6AVLSaN2nVVeWiF4y/view **Root Cause** Purchase Orders store the partner exactly as selected (the individual contact), while Vendor Bills are normalized internally to the parent company (`commercial_partner_id`). This creates a mismatch in the Bill Matching logic, where records reference both the individual and the company, leading to an invalid recordset and the singleton error. **Fix** Always normalize vendors to their `commercial_partner_id` during Bill Matching. This ensures that both Purchase Orders and Vendor Bills consistently reference the same partner, avoiding mismatches between individual contacts and their parent company. Opw-5050339 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#226130
Restaurant point-of-sale orders now save the latest added items before they are sent to kitchen displays or printers. This prevents outdated order errors and helps staff avoid service interruptions or missing order updates.
Original PR description
Before this commit, if an order had no changes and no preparation display was active, adding items to the order in the restaurant PoS and then returning to the tables would sync the order to the server and mark it as not dirty. As a result, reopening the order and clicking the order button to send it to the preparation display or printer would not sync the updated changes. This caused inconsistencies and errors. Steps to reproduce: 1. Open a table, place an order, and send it to the kitchen printer 2. Add more products but instead of placing the order, go back 3. Re-enter the table, place the order, and send it 4. When placing another order, the error "Order Outdated" appears This commit fixes the syncing logic to ensure that last changes are properly synced, avoiding the "Order Outdated" error. opw-5097566 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#227824
This fix improves the reliability of call controls and warning indicators in Discuss. Users are less likely to join a call with their microphone incorrectly muted, and connection warnings should remain visible during recovery steps.
Original PR description
This commit fixes: - the SFU could send outdated information about our own session during the initialisation of the connection. This can lead to the microphone being muted when joining a call if the updates occur when the user rtc session is marked as mute when querying the audio stream. - the warning indicator was hidden if the connection state was undefined this could lead to a missing warning during some recovery steps when session data is reset. Forward-Port-Of: odoo/odoo#228601
Orders placed through self-ordering or kiosk flows with online payment now appear on the preparation display only after payment is confirmed. This prevents staff from preparing unpaid orders while still ensuring paid orders reach the preparation screen even if the customer exits through the payment portal.
Original PR description
pos_*= pos_online_payment_self_order_preparation_display, pos_self_order_iot Before this commit, if an online payment method was assigned to a self or a kiosk, the order was displayed on the preparation display before the payment was confirmed. After this commit, the order is no longer displayed on the preparation display until the payment confirmation. Community PR: https://github.com/odoo/enterprise/pull/87173 Backport of https://github.com/odoo/odoo/pull/87173, with additional logic to ensure the order is correctly sent to the preparation display even if an exit route is used in the payment portal
This fixes an issue where users working across multiple companies could be blocked from adding Helpdesk timesheets when the linked project had no company set. It preserves the correct company during timesheet creation, preventing validation errors and supporting smoother Helpdesk billing and migration flows.
Original PR description
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the…
Steps to Reproduce: ------------------ - Open Helpdesk. - Go to Configuration → Helpdesk Teams. - Create a new team. - Enable the Billing feature and assign a project to this team. - Set the project’s Company field to Null. - Create an employee for the current user in another company. - Ensure the user has employees in both companies. - Create a new ticket (or open an existing one) in the newly created team. - Try creating a new timesheet → a Validation Error is raised. Root Cause: ----------------- When a user has employees associated with multiple companies and tries to log a timesheet with multi-company enabled, a validation error occurs. **This happens because:** - The default company is derived from the project linked to the Helpdesk team. Since the company_id field on the project is no longer required, it may be Null, leading to an error when fetching the correct [employee for the company](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216 ). - Additionally, the [company check](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82) is incorrect. The code is checking whether the `company_id` key exists in a `list of vals`, whereas it should be checked directly on the vals dict itself. Issue Faced: ------------- In version 18.3, timesheets are created during migration [here](https://github.com/odoo/upgrade/blob/24f85bbc3408bf10b1cee93e4c395edf806beaa8/migrations/helpdesk_timesheet/saas~18.3.1.0/post-migrate.py#L44-L58 ). Even though the correct company_id is passed, it gets overridden during the process. and If the associated project does not have a company set, the company_id becomes False [here](https://github.com/odoo/enterprise/blob/83a1b88c8cae4db5c9b1bf82ee7ebb4e13c41b2a/helpdesk_timesheet/models/analytic.py#L81-L82), which results in a Validation Error because the [here](https://github.com/odoo/odoo/blob/6a36015e2ee69aafe3880bf1fff38439af5cd673/addons/hr_timesheet/models/hr_timesheet.py#L214-L216) unable to determine the correct employee linked to the company. OPW: 5004092 Forward-Port-Of: odoo/enterprise#95226 Forward-Port-Of: odoo/enterprise#92507
Customer payments are no longer incorrectly included in Australia's Taxable Payments Annual Report gross paid amount. This keeps the report focused on eligible supplier bill payments, improving accuracy for annual compliance reporting.
Original PR description
Customer payment shoudn't be included in the TPAR report Steps: - Unarchive 10% TPAR tax - Make a bill for a partner X, set 10% TPAR tax on the invoice line and confirm - Create and confirm a customer payment for partner X - Go to 'Taxable Payments Annual Reports (TPAR)' -> The column 'Gross Paid' includes the customer payment Before this commit, we took all line from bank or cash journal to calculate the gross paid value. With this commit, we also restrict the lines to include only the one with 'asset_current' or 'liablility_current' account type. Ticket [link](https://www.odoo.com/odoo/project/967/tasks/5045457) opw-5045457 Forward-Port-Of: odoo/enterprise#95560 Forward-Port-Of: odoo/enterprise#95029
The point of sale now checks connected device status less frequently, moving from every 5 seconds to every 60 seconds. This reduces unnecessary background activity and can help keep PoS performance smoother for businesses with large product databases.
Original PR description
We currently check the status of the connected devices every 5s. This is used in only a short selection of the devices and the delay is unnecessarily short. For databases with a lot of products this can unnecesarily slow down their PoS This PR increases the loop until 60s opw-5006302 Forward-Port-Of: odoo/enterprise#92615
Shipping label printing can now use a printer selected for each operation type instead of automatically using the first compatible printer. This helps warehouses route labels to the right printer for different shipping workflows and reduces misprinted or misplaced labels.
Original PR description
Printing shipping labels is performed from the backend, once the shipping info are received in the chatter. The printing command is sent to the frontend via the user bus, then though longpolling to the iot box. This commit adds the possibility to select a printer instead of choosing automatically the first (with the right report associated) on the list. As the change is made on a stable version, we are using system parameters to store the selected printer without adding a new field. We associate a printer with the picking type, in order for to be able to have different printers by default on different picking types. Task: 4792491 Forward-Port-Of: odoo/enterprise#86818
Invoices can once again be printed through IoT-connected printers from Point of Sale instead of only being downloaded. This restores expected store workflows after a prior change disrupted invoice printing, and also makes printer selection easier to reuse in related printing flows.
Original PR description
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself. - **[REF] iot: extract printer select into separate function** Before this commit, the printer…
This PR contains two commits, the first is a refactoring, and the second is the invoice printing itself.
- **[REF] iot: extract printer select into separate function**
Before this commit, the printer selection wizard was tightly coupled to
the IoT report handler, and the call to send to the printer was
duplicated in the wizard and the handler.
After this commit, the printer selection wizard is contained in a
function that will always return the selected printers directly to the
caller, whether the dialog needs to be opened or not. The wizard is
simplified as a result and the print call always occurs in the handler.
This refactoring will allow other places to use the printer selection
wizard, namely for invoice printing.
- **[FIX] pos_iot: print invoices via IoT**
In the commit https://github.com/odoo/enterprise/commit/07418d7544ceecfef38257db8f59bf845a0b0769, the invoice PDF downloading was refactored to
bypass the `ir.actions.report` model, instead working directly via an
action on the invoice model. A side effect of this is that it broke
printing invoices via the IoT, as it relies on the report printing
action to function.
To fix this, this commit introduces an override in `pos_iot` for the
`account_move_service`, which will print the invoice PDF via the IoT
instead of downloading it directly (if a printer is associated with the
report).
task-5109814
Forward-Port-Of: odoo/enterprise#95586