Tuesday, October 28, 2025
8 changes · master
Resolved issues and error corrections
This fix ensures Brazilian AvaTax users see the custom product list views needed to correct tax-related product data. It restores access to key Brazilian fields, inline editing, and product navigation, avoiding an unsuitable standard product list.
Original PR description
The actionable_errors widget was changed to ignore views if a view_mode key is present in the action [1]. It caused the standard product.product list view to pop up, which doesn't work in this case. The custom views have the relevant Brazilian fields (SPED type etc), can be edited inline, and have a "View" button allowing the user to go to the product form view. The standard view has none of these. [1] odoo/odoo@3bd833c73ea654d8558e3d9701ad41e4d75ddd6 opw-5154766 Forward-Port-Of: odoo/enterprise#98012
Invoices paid with a partial amount from the invoice payment widget will now stay marked as partially paid instead of being automatically closed with a write-off. This helps users keep control of small remaining balances and avoid unintended accounting adjustments.
Original PR description
Prevents the system from creating a write-off and marking an invoice as 'Fully Paid' when a partial payment (within tolerance) is reconciled from the invoice form. The invoice status will now correctly remain 'Partially Paid', giving the user control over the remaining balance. task-5114658 Forward-Port-Of: odoo/enterprise#95899
This update fixes issues in Colombian electronic invoicing where new vendor bills could miss their commercial status, repeated event submissions could block the process, and issuer acceptance events could be rejected by DIAN. This helps accounting teams process vendor bills and compliance events more reliably.
Original PR description
this commit solves following issues: - the commercial status was missing on newly created vendor bills - the flow got stuck when an event had already been sent and we tried to send it again - The accept by issuer event generated errors on DIAN's side task: 5064534 Forward-Port-Of: odoo/enterprise#95444
Fixed an issue where partially paid subscription upsell orders could show a down payment invoice amount of zero instead of the actual paid amount. This ensures customers and businesses see accurate invoiced amounts for partial online payments on upsell orders.
Original PR description
Version- 17.0 ### Issue: - When an upsell order is partially paid (e.g., 10% of the original amount), the generated downpayment invoice incorrectly displayed an invoiced amount of 0. ### Steps to reproduce: - Make an Upsell order of subscription. - Update the condition of Online Payment from 100% to 10% (in this case). - Make the payment of 10% from portal view. - The invoice amount will be shown as $0. ### Fix: - Updated `_get_subscription_qty_to_invoice` to correctly determine the invoiced quantity and amount for downpayment invoices on upsell orders. ### Impact: - The downpayment invoices for upsell orders now correctly reflect the actual invoiced amount. Forward-Port-Of: odoo/enterprise#97571 Forward-Port-Of: odoo/enterprise#96719
UPS shipping labels could fail to generate in production when a sender or shipper VAT number was not entered. This change avoids sending an empty tax ID to UPS, allowing labels to be created when VAT information is unavailable.
Original PR description
Only in production mode, if the sender or the shipper's VAT was not set, the UPS answer would be an error, preventing the label generation altogether. This is because we send an empty string if the VAT was not set, and UPS couldn't process it. Forward-Port-Of: odoo/enterprise#98227
Studio no longer allows users to set default values on fields that are defined as readonly. This prevents configuration choices that could cause inconsistent behavior or errors in business records where those defaults are not properly supported.
Original PR description
Before this commit, it was possible to set via Studio a default value for readonly fields. Functionally, this opened the floor for a variety of issues when the user set a default value that way on models that did not handle that (by providing a default in the Action or some other way) Decision has been made to remove that feature for fields defined in python as readonly. Task-5172619
Opening the invoicing dashboard no longer fails when Stripe card issuing is enabled but the company only has currencies unsupported by Stripe active. The system now avoids creating or selecting Stripe issuing journals unless a valid supported currency is available, improving reliability for localized company setups.
Original PR description
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. **Steps to…
Currently, an error occurs when a user opens the invoicing dashboard after activating the `hr_expense_stripe` module for Stripe card issuing with only unsupported currencies active. **Steps to replicate:** * Install `account` without demo * Set Company currency to INR and deactivate USD in currencies. * Install `hr_expense_stripe` > Open Invoicing you will get the error. `ValueError: Expected singleton: res.currency()` **RootCause:** * When `hr_expense_stripe` is installed, the compute method [1] checks for supported currencies and defaults to USD if none are found. But since USD is often inactive by default in localized online databases, `stripe_currency_id` ends up empty . * Which causes [2] to pass an empty `stripe_currency_id` to [3], which expects at least one record, leading to the error. **Solution:** * Avoid creation of stripe issuance journal during installation when currency is not supported. * Add a constraint to check if stripe currency is valid for creating stripe issuance journal. * prevent creation and selection of journal for stripe issuing from settings. * [Reference Images](https://www.notion.so/Changes-in-Stripe-issuing-unsupported-vs-supported-2856722d865e803e8da1ece29cce7582?source=copy_link) for before and after functionality [1]: https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/hr_expense_stripe/models/res_company.py#L72 [2]: https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/hr_expense_stripe/models/account_journal.py#L52 [3]: https://github.com/odoo/odoo/blob/98bae80f57733162c67593539ef47dfd0c6d8797/odoo/addons/base/models/res_currency.py#L205 sentry-6916946380 Forward-Port-Of: odoo/enterprise#96271
Changing rental dates in the online cart now keeps the cart layout stable and preserves interactive quantity controls. This prevents shoppers from getting stuck when adjusting rental periods, improving checkout reliability.
Original PR description
Steps to reproduce: =================== 1. Add a meeting product to the cart with the "Rental" option checked. 2. Go to the cart and change the date range. → The cart layout shifts to the left, and…
Steps to reproduce: =================== 1. Add a meeting product to the cart with the "Rental" option checked. 2. Go to the cart and change the date range. → The cart layout shifts to the left, and quantity buttons become unclickable. Cause: ====== Two separate issues caused this behavior: 1. **Layout shift:** When updating the date range, `cart_quantity` can be undefined. The logic that determines whether to toggle the `col-lg-7` class relies on this value. When undefined, it incorrectly assumes the cart is empty and shifts the layout to the left. 2. **Unclickable buttons:** The following line replaces the entire `.js_cart_lines` element: https://github.com/odoo/odoo/blob/abf9bc083c5a219a0b6fc0346dcd2a2cb503e081/addons/website_sale/static/src/js/website_sale_utils.js#L88 This removes all old elements (and their event listeners) and inserts new ones from the server. As a result, interactive buttons (e.g., quantity update) lose their functionality. Older versions didn't face this issue because they used jQuery event delegation, which automatically handled dynamic elements. Solution: ========= 1. provide the cart_quantity value via the controller, 2. Restart the cart interaction after re-rendering to restore event bindings for clickable buttons. opw-5167866 Forward-Port-Of: odoo/enterprise#97715