Wednesday, September 24, 2025
13 changes · 17.0
Resolved issues and error corrections
Imported Chilean supplier invoices now correctly treat lines marked with exemption code 6 as negative amounts. This prevents vendor bills from being recorded with overstated positive values, improving accounting accuracy for affected DTE imports.
Original PR description
### Issue: When, in a DTE file, a line has the code 6 in `IndExe`. The amount of the line is supposed to be negative. (See the [doc](https://www.sii.cl/factura_electronica/formato_dte.pdf) page 31/32) ### Steps to reproduce: - Install 'l10n_cl_edi' and switrch to a Chilean company - Have a DTE file with a line having '6' in `IndExe`: - In Accounting > Vendor > Bills, click the button "Upload" and select the DTE file - The imported move has positive values on the every lines ### Cause: The values of `IndExe` are not considered. ### Solution: Add a condition changing the sign of `price_unit` when 6 is in `IndExe` opw-4954723
Odoo now accepts Taiwan VAT numbers under the latest official validation rules. This prevents valid new Taiwanese business identifiers from being incorrectly rejected as number ranges expand.
Original PR description
As the number of UBN in taiwan is expected to be exhausted, the numbers have been expended. To do so, the verification logic has been revised from the checksum being divisible by 10 to it being divisible by 5. stdnum is not yet supporting this new validation, and if it does it will take some time for Odoo to use the updated package, so we will handle the validation ourselves from now on. see https://www.ntbna.gov.tw/singlehtml/bbabfd4af20541b7859b4c5a099081f6?cntId=0625114d47274366baab1d3317f866ab task-5064712 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#225468
Subscriptions linked to archived companies are now skipped by the automatic recurring invoice process. This prevents hidden or unexpected invoices from being created for companies that users have intentionally archived, reducing cleanup work and billing confusion.
Original PR description
This commit is a backport of: https://github.com/odoo/enterprise/commit/a93e7eccc1b6bc39ad50771c696cb9cd6fef2ba4 Currently, when a company which has recurring orders (subscriptions) active is…
This commit is a backport of: https://github.com/odoo/enterprise/commit/a93e7eccc1b6bc39ad50771c696cb9cd6fef2ba4 Currently, when a company which has recurring orders (subscriptions) active is archived, the cron still periodically invoices them as usual but the user is not able to see it because they don't show up in the views. To avoid having to unarchive the comany and check every subscription one by one, this PR aims at making the cron ignore any subscription tied to an archived company, as intended. The only modified cron is the one that creates invoices since the other one of interest (the one that sends reminders) operates only on invoiced orders, which we avoid having with this change. Also added a test to ensure that if the company related to a subscription sale order is archived, the cron won't invoice it. ## Steps to reproduce: - Create a company A - Create a subscription belonging to company A with a next invoice date <= today - Archive the company - Run the scheduled action “Sale Subscription: generate recurring invoices and payments” The deferred information in the Settings must be correct - Unarchive the company and check the subscription. It has been invoiced. You may need to add back the Company A from the Allowed Companies of the user backport-of: a93e7ec opw-4904325
This fix prevents users from accidentally trying to send a WhatsApp message without choosing a required template. Instead of causing an unexpected error, the system now blocks the action and guides users to select a template first.
Original PR description
Currently, an error occurs when the user attempts to send a whatsapp message without selecting a template. **Steps to Reproduce:** 1. Configure a WhatsApp Business Account and synchronize the templates. 2. Open any contact and click the **WhatsApp** button next to the phone number. 3. Remove the template and click **Send Message**. **Error:** `ValueError - Expected singleton: whatsapp.template()` **Cause:** At [1], it attempts to fetch the formatted body and header from the template ID. Since no template is selected, it results in an error. **Fix:** This commit makes the field `wa_template_id` required, preventing users from sending a whatsapp message without a template. In stable versions, raise a validation error if a user attempts to send a message without selecting a template. [1] - https://github.com/odoo/enterprise/blob/fff9ad7999d4ff13adf899b2517e750a36c1261a/whatsapp/wizard/whatsapp_composer.py#L319 sentry-6854466874
This fixes a regression that prevented portal users from creating project tasks by sending an email to a project alias. It restores an expected collaboration workflow, so external users can continue submitting tasks without manual intervention.
Original PR description
The new safety belt introduced in 745f3accaf775550294d6f1bf562a0dcc15f7a08 made it impossible for portal users to create tasks by sending emails to the project alias. @moduon MT-11332 Forward-Port-Of: odoo/odoo#225321
The online shop now updates available stock correctly when customers add either a kit product or one of its components to their cart. This prevents shoppers from seeing misleading availability and helps avoid overselling when kit and component products share the same inventory.
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-prSale orders now avoid automatically selecting a sales team from a company the user cannot access. This prevents save errors when shared customers have sales teams assigned in another company, making multi-company order entry more reliable.
Original PR description
**Steps to reproduce:** - Create two companies. - Create two sales teams, each assigned to a different company. - Create a customer without a company (shared across both companies), and assign it a sales team from the first company. - Create a user belonging to the second company and its sales team. - With this user, create a new sale order for the shared customer. - The sales team field is automatically populated with the team from the other company. - An error is raised when saving the order. **Issue:** `_compute_team_id` does not validate allowed companies when determining `default_team_id`. As a result, `order.partner_id.team_id` could be used even if the user did not have access to the company of this team. **Fix:** Explicitly check if the proposed teams are available to the user in `self.env.companies.ids`. opw-4920130 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Customers using self-order can now go back from the payment page without losing the items already in their cart. This prevents checkout frustration and keeps cart updates accurate when customers change their order before paying.
Original PR description
Steps to reproduce: =================== - Start a self-order session. - Add some products to the cart. - Navigate to the payment page. - Click the back button. Issue: ====== - The previous order state is lost when going back from the payment page. - Not able to update the cart after click on the pay button. Cause: ====== - No code existed to preserve the current order state before navigation. - The server kept old lines even if the client removed them from the payload, preventing proper synchronization. Fix: ==== - Added preservation of order details (`lines`, `lastChangesSent`) so that the state can be restored when navigating back. - Implemented removal of order lines that are no longer present in the incoming payload. Task: 5055279
Users can now change the owner of selected documents in list view without losing their selection. This makes it easier to apply several actions in a row and avoids repeating document selections.
Original PR description
Steps to reproduce: 1. Go to Documents app 2. Select one or multiple documents in list view. 3. Change the owner of the selected document(s). 4. Selection is lost. The migration to Odoo 17's new architecture removed the selection preservation logic previously handled by `DocumentsDataPointMixin` in Odoo 16, resulting in records being deselected after inline field updates. This commit restores the selection preservation behavior by implementing the necessary logic in `DocumentsModelMixin`'s update method, ensuring consistent UX when performing multiple operations on selected records. opw-4699629
This update corrects an automated test in the SEPA payments area so it follows the system’s allowed way of handling bank account data. It helps keep testing reliable without changing day-to-day user functionality.
Original PR description
Direct update sanitized_acc_number is not allowed.
This fix stops locked sanitized bank account numbers from being updated. It helps preserve the integrity of stored bank account information and reduces the risk of accidental or unauthorized changes.
Original PR description
Before this fix it was possible to update sanitized_acc_number even if it is locked.
Odoo now stops users from validating a stock transfer when there is no actual quantity to process. This avoids showing a confusing backorder prompt that cannot create a meaningful backorder, helping warehouse users catch the issue immediately.
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-prThis fix restores a missing database index used by stock rules for company-related records. It helps keep upgrades cleaner by preventing misleading system log messages and preserves expected performance behavior.
Original PR description
due to conflict on this forward port https://github.com/odoo/odoo/pull/113045 ``index=True`` was removed according to this pr https://github.com/odoo/odoo/pull/90531 So, adding it back during upgrade it shows misleading logs ``` 2025-08-26 22:19:25,039 23 INFO db_3112946 odoo.schema: Keep unexpected index stock_rule_company_id_index on table stock_rule ``` opw-5052223 upg-3112946 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr