Thursday, October 2, 2025
12 changes · saas-18.3
Enhancements to existing features
This update improves how Point of Sale orders handle taxes, fiscal positions, product configuration, receipts, and customer display information. It helps make checkout totals and order details more consistent across related POS flows such as restaurant bills, events, loyalty, sales, and self-ordering.
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 update improves Point of Sale behavior across several localization and payment areas, including certified scale display, Italian fiscal documents, Belgian blackbox flows, and settling due amounts. These changes help stores meet local compliance requirements and provide smoother checkout/payment handling.
Approved leave that uses a work leave type will no longer automatically create a timesheet entry. This keeps timesheet records cleaner and avoids extra entries for time off that should not be tracked as worked time.
Original PR description
When a leave using a work leave type is approved, now it should not create a timesheet. task-5097482 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#229568 Forward-Port-Of: odoo/odoo#229300
Resolved issues and error corrections
Recurring subscription invoicing now skips subscriptions linked to archived companies. This prevents customers from being billed while their company record is inactive, reducing incorrect invoices and follow-up corrections.
Original PR description
## Issue: When a company with active subscriptions is archived, the recurring invoicing cron still processes these subscriptions. Subscriptions for archived companies must not be invoiced. ## Steps to reproduce: 1. Create a company A. 2. Create a subscription for company A with next invoice date <= today. 3. Archive the company. 4. Run the scheduled action "Sale Subscription: generate recurring invoices and payments". 5. Unarchive the company and check the subscription. It should not have been invoiced. (Adjust the user's Allowed Companies if needed to access it.) backport-of: a93e7ec opw-4904325 Forward-Port-Of: odoo/enterprise#95408
This fixes an issue where changing followers on multiple records at once could incorrectly leave some followers subscribed or unsubscribed. The mail module now handles removals after processing the full batch, making follower updates more reliable for users working with multiple records.
Original PR description
When updating `message_partner_ids` on a batch of records, the previous implementation of the inverse method could lead to incorrect results if the new value implied unsubscription. The `message_unsubscribe()` method, called inside the loop over the records, unlinks `mail.followers`. This `unlink` operation invalidates all the fields cache. As a result, when processing the next record in the batch, its cached fields (the new value of `message_follower_ids`) were erased, causing the logic to fail. This commit fixes the issue by postponing all unsubscription operations. opw-5050023 Forward-Port-Of: odoo/odoo#227499
This fixes an issue where increasing the quantity on a sales order using a customized warehouse route could create an incorrect extra delivery quantity. Businesses using multi-step deliveries and custom internal routes will now get the right remaining quantity to pick and ship, reducing fulfillment errors.
Original PR description
**Steps to reproduce:** - enable multi-step routes setting. - navigate to warehouse management/locations create a new location (the "test location"). - select "internal location" for the location…
**Steps to reproduce:** - enable multi-step routes setting. - navigate to warehouse management/locations create a new location (the "test location"). - select "internal location" for the location type. - select WH for the parent location - navigate to warehouse management/warehouses and select the warehouse corresponding to WH. - set the warehouse in 3 steps delivery. - click on the routes smart button. - click on the "deliver in 3 steps (pick+pack+ship)" route. - add a rule, for the action select "push to", for the operation type select "internal transfers", for the source location select the "test location" you just created and for destination location select "WH/Output". - save. - create a storable product and set an on-hand quantity - create a new sale order for 1 quantity of this product and confirm it - click on the picking smart button, change the destination location to the test location and validate - open the sale order and change the quantity to 3 **Current behavior:** A new picking is created from stock to packing zone (which is the expected behavior) but the quantity is 1 **Expected behavior:** The quantity should be 2. If we only increase the quantity by 1 on the sale order it does not even create the new picking **Cause of the issue:** The warehouse_id field is invisible in stock.rule form view when the action is push. Therefore, the rule is created without a warehouse_id. Also, moves created from a rule have the same warehouse_id as the rule. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/stock/models/stock_rule.py#L275 So, when we validated our first move (from stock to the test location), this created a second move (from test location to output) that does not have a warehouse id (because it was created from our own push rule that we created). When we update the quantity of the sale ordre line, _action_launch_stock_rule calls _get_quantity_procurement to compute the current quantity on the moves. This method then calls _get_outgoing_incoming_moves to get the initial move created from the rule. In this case this should return only the first move created. But because the second move does not have a warehouse_id, it's rule.id is added to triggering_rule_ids. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L315-L317 And the move is later added to the outgoing moves that will be returned. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L322-L329 So the two moves are returned and the sum of the quantities of the moves is 2 instead of 1. https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L292-L294 So the product quantity for the procurement will be 1 (3-2) instead of 2 (3-1). https://github.com/odoo/odoo/blob/a729578afb7fed79aac2d622aae4da4c0917f8e5/addons/sale_stock/models/sale_order_line.py#L386 opw-5039249 Forward-Port-Of: odoo/odoo#228812 Forward-Port-Of: odoo/odoo#227421
Inventory revaluation calculations now keep full precision until the final result is ready. This prevents small rounding differences from accumulating into incorrect or negative valuation amounts, improving the reliability of stock accounting.
Original PR description
Before this commit, the remaining_value_unit_cost was rounded before any computation. In the case where the numer of layers with remaining value and remaining quantity increase, the rounding error introduced by that rounding quickly explodes, leading to a negative remaining_value during revaluation computation. After this commit, the remaining value is rounded at the end, after the computations and the checks. This ensures that the rounding error remains constant and does not accumulate over the execution of the method. opw-4901966 Forward-Port-Of: odoo/odoo#228767 Forward-Port-Of: odoo/odoo#222690
Uploaded file fields added to field service worksheet templates now appear correctly in the customer-facing worksheet report. This ensures customers and staff can see attached files during report review and signing, avoiding missing information in the portal.
Original PR description
Steps to reproduce: ------- - Install industry_fsm_report module - Open FSM app - Select worksheets from settings in the configuration - Go to worksheet templates in the configuration - Create a worksheet template - Click the design template button. You arrive in the studio - Add file field and close it - Create a new task and select a newly created template in the worksheet template - Click the worksheet button in the control panel - Upload a file and save it - Click on the sign report button - Here file field is not visible Issue: ------- The file field is not visible in the worksheet portal. Cause: ------ The view of the file field is not created for the worksheet portal. Solution: ------- Created the view of the file field to display in the worksheet portal. task-3691529 Forward-Port-Of: odoo/enterprise#95754 Forward-Port-Of: odoo/enterprise#56035
Self-order purchases paid online now reach the preparation display before any cashier-side print confirmation is handled. This prevents kitchen or preparation teams from waiting on an unattended cashier popup before seeing new orders.
Original PR description
When ordering from a self order and paying online, the ticket would be printed at the cashier. If the config doesn't use any physical printer it will fallback on webprint. In this case the cashier…
When ordering from a self order and paying online, the ticket would be printed at the cashier. If the config doesn't use any physical printer it will fallback on webprint. In this case the cashier would need to print via the popup on his screen. But as we are awaiting the printing to be done, the receipt screen is not updated until the cashier has closed the popup. Steps to reproduce: ------------------- * Setup a PoS to use self order and online payment. * Make sure the PoS doesn't have any printer setup. * Setup a preparation display for the PoS. * Make sure the PoS is not a restaurant. * Open the PoS, the kiosk and the preparation display on different pages * Make an order on the kiosk and pay for it. * Go to the PoS, you should see a popup trying to print the ticket. > Observation: The preparation display is not updated until the printing popup is processed. Why the fix: ------------ To make sure the preparation display is always up to date, we send the order first to the prepartion display and then to the cashier. So that if no one is at the cashier the preparation display is still updated. opw-5111555
This fix prevents signed signature requests from being deleted after completion. It helps protect completed agreements and reduces the risk of losing important signed documents.
Original PR description
backport of https://github.com/odoo/enterprise/commit/b2d32811877cdf1649095435ce16274ae96421f3 opw-5111568 Forward-Port-Of: odoo/enterprise#96025 Forward-Port-Of: odoo/enterprise#95922
Pasting over selected link text in the HTML editor now respects links that should not be removed, such as protected menu items or non-editable content. This prevents users from accidentally deleting important website navigation or protected content while editing.
Original PR description
When the label of a link is fully selected and the user pastes some text, the link is removed. It was removed even if the link was in a `contenteditable=false` or was unremovable. This commit only…
When the label of a link is fully selected and the user pastes some text, the link is removed. It was removed even if the link was in a `contenteditable=false` or was unremovable. This commit only attempts to remove the link element after checking these conditions. It also only selects the link in the `before_paste` handler, and lets the normal paste logic remove it. Steps to reproduce (after 18.4, where it was noticed): - Copy some simple text - Open website builder - Select completely the label of a menu in the header - Paste - Bug: the menu item is removed, and replaced with simple text Steps to reproduce (in 18.0 and later): - Open "To-Do" app - Add a link in the middle of a line of text - With inspector, edit html to put `contenteditable="false"` on the container of the line, and `contenteditable="true"` on the link - Select completely the label of the link in the document - Paste some text - Bug: the link is removed, and the clipboard content is inserted after the non editable element task-5110141 Forward-Port-Of: odoo/odoo#228223
The Spanish Modelo 303 VAT return now ignores unrelated tax tags when preparing closing entries. This helps prevent incorrect VAT closing amounts and improves the reliability of Spanish tax reporting.
Original PR description
Before this commit the domain of the modelo 303 would take into account irrelevant tax_tags, causing the closing entry to be incorrect. Fixed this by adding an additional domain to the _get_vat_closing_entry_additional_domain function.