Friday, October 24, 2025
22 changes · saas-18.3
Resolved issues and error corrections
The Chinese accounting reports now include the right balance sheet lines and account mapping for ASBE reporting. This helps ensure the balance sheet balances correctly, improving confidence in statutory financial reports.
Original PR description
Fixes the balance_sheet_balanced test for asbe where the wrong line was set as liability. Also fixes the report itself that was ignoring one line, and missing one account. task-5175789 Forward-Port-Of: odoo/enterprise#97720 Forward-Port-Of: odoo/enterprise#97460
Spanish point-of-sale receipts now display the company’s state name instead of empty brackets. This avoids confusing or incomplete receipt information when simplified invoices are issued.
Original PR description
**Steps to reproduce:** - Set a spanish company, set the state - Set the "Simplified Invoice" journal in the settings - Go to PoS and make a purchase - On the receipt, empty brackets are shown where the state should be **Why the fix:** Before this commit, we checked that the company had a state set, and if it had, we displayed *state_id[1]* between brackets. Even if the state_id existed, this is not the correct structure for the state_id, so *state_id[1]* did not exist, and we displayed only the brackets. We now display the correct state name, still between brackets. opw-5098212 Forward-Port-Of: odoo/odoo#232689 Forward-Port-Of: odoo/odoo#230141
This fix updates Vietnam localization migrations so only the necessary tax records are refreshed instead of reloading the full accounting setup. This helps prevent customized accounting configurations from being overwritten during upgrades.
Original PR description
Problem The previous implementation used try_loading() which would reload the entire chart template, potentially overwriting user-customized configurations settings. Solution Replaced try_loading() with a more targeted approach usin _load_data for account.tax.group and account.tax 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#229476 Forward-Port-Of: odoo/odoo#227918
Fixed an issue where grouping sales commission achievements often showed an empty list. The report now uses the correct paging values, so business users can reliably review grouped achievement data.
Original PR description
Before this commit, grouping achievements would result in empty list most of the time. It happened because offset and limit were switched by mistake in the override. As a result an offset of 80 was applied in the request during group by.
Website table bookings now correctly copy the customer's phone number into the appointment. This helps staff see the right contact details for reservations without changing the underlying customer record.
Original PR description
Task: [#5005216](https://www.odoo.com/odoo/project/1737/tasks/5005216) --- The phone number field was not being populated correctly when booking a table from the website. It is now properly filled using the phone number of the `res.partner` associated with the appointment. The field remains unlinked to the partner, as it is just a copy.
Failed mass mailing campaigns with hundreds of thousands of recipients can now be retried without running out of memory. This helps larger customers recover from temporary mail server outages and complete their campaigns more reliably.
Original PR description
Steps to reproduce the issue: 1. Have 100s of thousands of recipients on a campaign 2. Disconnect your outgoing server and send 3. Reconnect the mailing server and retry sending. Current behavior before PR: A `MemoryError` is raised due to the large number of emails processed to `unlink()` Desired behavior after PR is merged: Larger-scale clients would be able to resend 100s of thousands of emails if they fail opw-5091567 Forward-Port-Of: odoo/odoo#228446
The Field Service “To Schedule” view now excludes tasks that are already done or cancelled. This helps teams focus only on work that still needs scheduling or assignment, reducing clutter and confusion.
Original PR description
**steps to reproduce:** Go to field service Go to all tasks > to schedule **issue:** The To Schedule filter was also displaying tasks in cancelled or done state, whereas it should only show open tasks that need to be scheduled or assigned. **cause:** The filter domain did not exclude cancelled/done state, causing closed tasks to appear in the filtered view. **fix:** Updated the filter domain to exclude cancelled/done state, to ensure only open tasks are shown under the To Schedule filter. task-5138590 Forward-Port-Of: odoo/enterprise#96600
This update corrects how delivery information is included in Turkish Nilvera e-invoices, so it appears only when required and in the expected place. This prevents export e-invoices with discounts from being blocked by Nilvera, improving reliability for affected invoicing flows.
Original PR description
The Delivery node is only required for Export E-Invoices. Additionally, the position of the Delivery node should not follow the AllowanceCharge node. This inconsistency in node positioning causes a blocking issue on Nilvera’s side, preventing the successful processing of export E-Invoices with discounts. task-5155802 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#230935
Landscape PDF reports printed through a Virtual IoT Box now keep their intended page orientation instead of being cropped as portrait pages. This helps businesses avoid incorrectly printed documents and reduces reprinting or manual fixes.
Original PR description
When printing a landscape report using a Virtual IoT Box, we end up printing a portrait page cropped. This commit adds the "pdf fit page" argument to ensure the page printed follows the report orientation. opw-5051809 Task: 5149706 Forward-Port-Of: odoo/odoo#232866
This fix stops shared accounting accounts from being deleted when they are still used by journal entries in another company. It helps protect accounting data in multi-company setups and avoids inconsistencies across shared company records.
Original PR description
In a multi-company environment, accounts can be shared. A Python constraint prevents deleting an account if it has journal items in the current company. However, this check was missing when an account only contained journal items belonging to other shared companies. This commit fixes the issue by: 1. Updating the `ondelete` attribute of the `account_id` field on `account.move.line` to cascade the restriction at the database level. 2. Updating the existing Python constraint on `account.account` to enforce this logic in stable versions without a module update (this will be removed in the master branch). task-5158966 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232530
Splitting a delivery now correctly updates the stock availability status of the original delivery line. This helps warehouse users see accurate fulfillment information after part of a delivery is separated into a new picking.
Original PR description
Steps to reproduce: - Create a storable product “P1” - Update its quantity to 10 - Create a delivery picking with 10 units of P1 - Confirm → The picking is in “Ready” state and the move is “Available” - Update the “Quantity” of P1 to 6 units in the picking → The move state is recomputed to “Partially Available”, since the demanded quantity exceeds the quantity done. https://github.com/odoo/odoo/blob/18.0/addons/stock/models/stock_move.py#L2207-L2208 - Split the picking Problem: A new picking is created with 4 units in quantity and its move is “Available”, but the original move with 6 units does not have its state recomputed. opw-5173374 Forward-Port-Of: odoo/odoo#232516
A website blog automated check no longer depends on the English name for October. This prevents the check from failing when the website uses another language, helping keep multilingual blog features reliably tested.
Original PR description
Before this commit the blog_tags_with_date tour tried to select the October option by label. In other locales the month label differs and the tour could not find it, so the tour aborted at that step. Steps to reproduce: - Change the website language to one where October has another name. - Run the blog_tags_with_date preview tour. The tour now selects the first month option by index, independent of labels. runbot-233321 Forward-Port-Of: odoo/odoo#232610
The web test runner now handles cases where users click Run before all test assets have finished loading. This prevents an early-click crash in manual test mode and makes internal testing more reliable.
Original PR description
Before this commit, in manual mode, "Run" could be clicked before the assets finished loading (and so, before the test runner was properly "ready"). This caused a crash because it tried to resolve a promise that did not exist yet. Steps to reproduce: - Go to test URL (manual) - Click "Run" as soon as the button is visible (probably via a script to make sure the click is fast enough) This commit fixes that by adding failsafes around that promise, effecitvely allowing to click "Run" early on. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232789
Fixed an accounting issue where fixed taxes on invoice lines with negative prices could appear as positive amounts. This ensures invoices and tax totals correctly reflect refunds, discounts, or other negative line items, reducing accounting discrepancies.
Original PR description
Steps to reproduce: 1. Create a fixed tax 2. Create a invoice with a product with negative price Problem: The amount of the tax is positive while the line is negative. opw-5128767 Forward-Port-Of: odoo/odoo#232084
This change corrects how fixed taxes are calculated when an accounting line has a negative price, such as a refund or reversal. It helps ensure totals remain accurate in accounting workflows and reduces the risk of incorrect tax amounts in bank statement scenarios.
Original PR description
opw-5128767
This update makes an automated website image test independent from demo data, reducing false failures in the testing pipeline. It helps keep releases stable by ensuring test results reflect real issues rather than differences in sample data.
Original PR description
runbot-162894 Forward-Port-Of: odoo/odoo#213962
This fixes an issue where the cash drawer would not open in Point of Sale if an unreachable IoT box was also configured. Stores using ePOS printers can now open the cash drawer reliably, even when unrelated connected devices are offline.
Original PR description
Steps to reproduce: 1. Configure a POS to use an ePOS printer with the cashdrawer enabled. 2. Also configure the POS to use an IoT box with a dummy device, e.g. '[Shop] Scale'. The important thing is that the IoT box is not reachable when the POS opens, so the dummy devices work well for this. 3. Open the POS, make an order and go to payment, then click 'Open cashbox'. Expected behaviour: The cashdrawer opens Actual behaviour: Nothing happens task-5059502 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#232852 Forward-Port-Of: odoo/odoo#232797
Fixed an issue that could prevent invoice previews from opening when a website page included map content. The invoice preview now selects the correct preview area, avoiding errors for accounting users.
Original PR description
Support the possibility of multiple iframes being present on the invoice preview page. Steps to reproduce ----- 1. Add a map block to the nav bar of the website. 2. Go to accounting and find an invoice. 3. Click preview and receive a traceback. Cause ----- The use of querySelector works if there is only one iframe element, but map blocks are also iframe elements so adding one with the website editor can cause the wrong iframe to be selected with querySelector. Solution ----- The iframe element that needs to be selected already has an id, so updating querySelector to getElementById resolves the issue. opw-ticket 5170640 Forward-Port-Of: odoo/odoo#232754
This fix ensures payments through Six terminals start correctly when a point-of-sale session is accessed by a different logged-in user. It prevents a missing user reference from interrupting payment processing, improving reliability for teams sharing POS workflows.
Original PR description
This commit fixes an undefined `user_id` on the pos session when trying to start a payment with a Six terminal from another user than the one that started the session. Before this commit: - open a pos session with Mitchell Admin, - check the value of `pos.session.user_id` (it will be `2`), - open another tab and connect as Marc Demo, - check the value of `pos.session.user_id` again: it should be `6`, but instead is `undefined`. After this commit: We use `pos.user.id` instead of `pos.session.user_id.id` to get the user ID. opw-5055977 Forward-Port-Of: odoo/enterprise#98021 Forward-Port-Of: odoo/enterprise#97975
This fix prevents chat and live chat screens from failing when a channel member is loaded without full contact details. Users will see the existing "unnamed" fallback instead of experiencing an error, keeping conversations accessible in affected flows.
Original PR description
Sometimes, channel members are received without their partner/guest because it's not important in the flow. However, some part of the JS code assume the persona is always set, resulting in errors. This PR guards access to persona when computing the member name, a fallback to "unnamed" is already in place. task-5184408 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
Users whose contact record is linked to multiple user accounts can now create spreadsheets from the Documents app without hitting an error. This prevents a blocking crash in a specific contact setup, keeping document spreadsheet creation reliable for affected users.
Original PR description
Before this commit: 1. connect with a user, the partner_id of which is linked to multiple users via the user_ids field (this can be done by manually setting it, or by merging contacts, for example) 2. go to the Documents app, click new, then spreadsheet --> expected singleton Traceback opw-5133850 Forward-Port-Of: odoo/enterprise#97767
The Barcode app now rounds the quantity shown on the fulfill button, preventing confusing long decimal values from appearing when processing receipts with decimal quantities. This makes inventory receipt handling clearer and avoids display-only precision errors for users.
Original PR description
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54)…
**Issue** In the Barcode application, floating-point values may display excessive decimals. **Steps to reproduce** - Open the Inventory app. - Create a receipt with a decimal quantity (e.g. 10.54) and mark it as To Do. - Open the Barcode app, open the corresponding receipt, and click the Edit button. - Increment the number of scans several times until you notice too many decimal digits (if you choose 10.54, you can test with 3). **Cause** A floating-point precision error occurs in the getter [`quantityToFulfill`](https://github.com/odoo/enterprise/blob/4b08734124c3bc84f7d95d170b39e9909e20d66b/stock_barcode/static/src/widgets/digipad.js#L55C9-L55C50), which is rendered directly [in XML templates](https://github.com/odoo/enterprise/blob/e8063141b33a9a8aa51d1ce94a66af313b2c1c89/stock_barcode/static/src/widgets/digipad.xml#L20C25-L21C89) without rounding. **Solution** Round the displayed value in the `quantityToFulfill` getter in the same manner than in [barcode_model](https://github.com/odoo/enterprise/blob/d4e5b69c7ea87fba3f2a5204ed6939b97879e4a8/stock_barcode/static/src/models/barcode_model.js#L99-L103). opw-5039796 Forward-Port-Of: odoo/enterprise#97475