Tuesday, September 2, 2025
7 changes · 17.0
Resolved issues and error corrections
This change restores support for customized partial editing permissions on website pages, especially for Odoo.com-specific use cases. It rolls back a prior logic change that fixed one issue but unintentionally broke some restricted editor workflows, while keeping the related test disabled until a fuller solution is found.
Original PR description
*: test_website This reverts commit [1]. Indeed, while it fixed the bug as intended while keeping the `_check_user_can_modify` feature, it apparently did not keep that one working in all cases: having partial view edition rights for some website.page (see uses in our Odoo.com customizations). While searching for a solution allowing to keep the fix of [1] and the whole purpose of `_check_user_can_modify`, the logic part of [1] is reverted, keeping the test but disabled. [1]: https://github.com/odoo/odoo/commit/8c41c147a4c6a415e7c5bfdde9297edbf40b4239
Reducing a subcontracted receipt quantity no longer cancels all related manufacturing orders. This keeps the receipt adjustable and prevents follow-up quantity changes from getting stuck.
Original PR description
Steps to reproduce:
- Unarchive subcontracting operation type
- Create a storable product P1 with a BoM:
- BoM type: Subcontracting
- Subcontractor: Azure Interior
- Component C1 (route: Resupply Subcontractor on Order)
- Create a purchase order:
- Vendor: Azure Interior
- 10 units of P1
- Confirm the PO → 2 pickings are created:
- Resupply of 10 units of C1
- Receipt of 10 units of P1
- Confirm and validate the resupply of C1
- Components are reserved in the subcontracting MO
- Validate the consumption of 10 units in the receipt
- The MO is updated to 10
- Update the quantity of P1 to 0 in the receipt
Issue:
The manufacturing order is cancelled. As a result, subsequent updates on the receipt cannot recreate MOs.
Fix:
When reducing the receipt quantity, cancel only the extra MOs, but always keep at least one open MO if a subcontracting move is still ongoing.
opw-4792379Vendor bills created from consolidated inter-company invoices now correctly recognize multiple purchase order references. This keeps the bill connected to the matching purchase orders, making follow-up and reconciliation easier for accounting and purchasing teams.
Original PR description
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated…
## Issue: In a multi-company setup with Inter-Company Transactions set to Sales Orders and Purchase Orders, after creating two Sales Orders from one company to the other, then generate a Consolidated Invoice for both SO, and import it as Vendor Bill in the client Company, the bill isn't linked to the matching Purchase Order ## Cause: The `invoice_origin` is used to get the references, but it doesn't split causing the purchase's name to search in `_match_purchase_orders()` to be ["P00001, P00002"] instead of ["P00001", "P00002"] https://github.com/odoo/odoo/blob/2718aaa7397e38be0fcd64fe6b5ef5c0be66cfe2/addons/purchase/models/account_invoice.py#L373-L374 ## Steps to reproduce: - Enable Inter-Company Transactions for Sales Orders and Purchase Orders in two Companies - Create and Confirm two Sales Orders from one company to the other one - Create a Consolidated Bill for both S0 - Send the Invoice (Download) - Switch to the second Company - In Purchase, Confirm both RFQ - In Accounting > Vendor > Bills, Upload the downloaded bill - The Smart Button isn't linked to the PO Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4690707) opw-4690707
Updating the scheduled date for one product line on a receipt no longer changes the scheduled dates of other product lines by mistake. This helps warehouse teams keep delivery and receipt planning accurate when editing individual stock moves.
Original PR description
### Steps to reproduce: - Install stock_delivery - Create and confirm a receipt for 2 products: - 1 x P1 - 1 x P2 - Modify the scheduled date of P1 to the day before - Save the picking #### Expected…
### Steps to reproduce:
- Install stock_delivery
- Create and confirm a receipt for 2 products:
- 1 x P1
- 1 x P2
- Modify the scheduled date of P1 to the day before
- Save the picking
#### Expected behavior:
The scheduled date of the picking is updated but not the one of the other move.
#### Current behavior:
The the move scheduled date is also updated.
### Cause of the issue:
Modifying the scheduled date of the move will trigger a call of the onchange on the picking because the `stock_move_ids` field has changed via a `Command.update` on its scheduled date:
https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/web/static/src/model/relational_model/record.js#L1214-L1219 However, this onchange will trigger a call of the
`_compute_scheduled_date` on the new records to determine if its value has changed and set the scheduled date of the picking to one day before: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L846-L851 This is problematic because since each of these changes happen before the save of the real record, the inverse method of the scheduled date will be called and set the scheduled date of the other moves at save: https://github.com/odoo/odoo/blob/697278b2e86e5e4ccf53e0d8ead172e3e2a01eea/addons/stock/models/stock_picking.py#L897-L901
### Note:
This is not reproducible without `stock_delivery`, changing the scheduled of a `move_ids_without_package` will only trigger the onchange of the `stock.picking` model (and hence the compute on the new records) in case the `move_ids_without_package` is flagged as `onchange=1` by the `get_view`:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/addons/base/models/ir_ui_view.py#L1218-L1225 But, since `move_ids_without_package` do not have `_onchange_methods` they will only be flagged as such if they are in the dependencies of a field present in the view:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/odoo/models.py#L7363-L7370 This is the case as soon as `stock_delivery` is installed because of the `is_return_picking` field:
https://github.com/odoo/odoo/blob/c9e8a802315be27a076ae677b9191c075e4c239d/addons/stock_delivery/models/stock_picking.py#L37-L38
opw-5017423
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fix prevents IoT boxes from being treated as new devices when they connect to databases on older versions. By sending both the serial number and MAC address, the system can correctly recognize and update the existing box, avoiding connection and token issues.
Original PR description
We are currently experiencing a bug with the image 25_07 build on saas-18.4 In this version the "identifier" used in iot app is the iot box's serial number In versions < 18.4 the identifier used is the iot box's mac address When connecting to a database in version 18.3 or less, the iot box: 1) Calls send_all_devices --> create a new iot box in the database with identifier = serial number 2) Runs git checkout to align itself to the database version 3) Calls send_all_devices again, this time with identifier = mac address 4) The database ignores the request because it considers it a new iot box with a different token This PR fixes the issue by sending both mac address and serial number to the database If the database has an iot box with the corresponding serial number as an identifier, it updates it. Enterprise PR: https://github.com/odoo/enterprise/pull/93657
This fix prevents IoT boxes from being rejected when connecting to older databases after an update changes how the box is identified. By sending both the serial number and MAC address, existing IoT boxes can be matched correctly and continue working without duplicate records or connection failures.
Original PR description
We are currently experiencing a bug with the image 25_07 build on saas-18.4 In this version the "identifier" used in iot app is the iot box's serial number In versions < 18.4 the identifier used is the iot box's mac address When connecting to a database in version 18.3 or less, the iot box: 1) Calls send_all_devices --> create a new iot box in the database with identifier = serial number 2) Runs git checkout to align itself to the database version 3) Calls send_all_devices again, this time with identifier = mac address 4) The database ignores the request because it considers it a new iot box with a different token This PR fixes the issue by sending both mac address and serial number to the database If the database has an iot box with the corresponding serial number as an identifier, it updates it. community PR: https://github.com/odoo/odoo/pull/225043
This fix prevents an error when users post several draft invoices at once using Avalara Brazil automatic tax mapping. It helps finance teams process invoices in bulk without interruptions or manual workarounds.
Original PR description
Issue:
When posting multiple invoices with Avalara Brazil tax mapping, a traceback is raised:
ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: account.move
Only occurs when fiscal position is set to:
Automatic Tax Mapping (Avalara Brazil)
Affected versions:
- 17.0 and later
Steps to reproduce:
1. Set Avalara connection
2. Create an invoice with fiscal position: Automatic Tax Mapping (Avalara Brazil)
3. Duplicate that invoice
4. Select two or more invoices in draft
5. Try to post those entries
https://drive.google.com/file/d/1_CjX9vGhr-ZyUegP9QhOdQ--bfA8ylsH/view?usp=sharing
Current behavior:
- Error is raised: ValueError: Expected singleton
Expected behavior:
- Invoices should post correctly without errors