Daily updates from Odoo
Monday, February 9, 2026
3 changes · master
Resolved issues and error corrections
This update prevents subscription discounts from being reset when the subscription's start date or plan is changed. Previously, date changes triggered a recalculation that wiped out manually entered commercial discounts. Now, the system checks if the line items have actually changed before recalculating discounts, ensuring user-defined discounts are maintained.
Original PR description
Before this commit, changing the `start_date` or `plan_id` on a Subscription would trigger a recomputation of the `discount` field on all order lines. This triggered the standard `_compute_discount`…
Before this commit, changing the `start_date` or `plan_id` on a Subscription would trigger a recomputation of the `discount` field on all order lines. This triggered the standard `_compute_discount` method, which recalculates the price and discount based on the Pricelist, effectively wiping out any manually entered commercial discounts. This occurred because the `_compute_discount` method in `sale_subscription` depends on `order_id.start_date` to calculate pro-rated amounts for upsells. However, it was unconditionally calling `super()`, which runs the standard pricelist logic even when the line content itself (Product, Qty) had not changed. This commit introduces a check to detect if the line content has actually been modified by the user (comparing against the database origin). - If the line content (Product, Qty, UoM) is unchanged, we skip the `super()` call to preserve the manual discount. - If the line content is changed (or it is a new line), we allow `super()` to run to update the price according to the pricelist. This ensures that contextual changes (like shifting the start date) do not destroy manual data entered on the lines. task: 5788384
This update simplifies how Odoo identifies downpayments by moving the related field from a custom 'is_downpayment' field to the 'display_type'. Previously, this required complex overrides across multiple modules, leading to potential instability. This change ensures downpayment logic is more reliable and easier to maintain.
Original PR description
*: helpdesk_sale_timesheet, industry_fsm_sale, l10n_mx_edi_landing, l10n_pe_edi, sale_external_tax, sale_subscription, --- Description of the issue this commit addresses: Currently the detection of whether a line (account move, sale order, purchase order) or a move is a downpayement relies on a `is_downpayment` field one the lines models. This creates complexity as overridable methods are put on account models so that when other module with downpayments are installed, they get overriden and the downpayment behavior is implemented. This means that the account module always calls those helper just in case of if one of those modules is installed. --- Desired behavior after this commit is merged: This commit migrates the `is_downpayment` field to a new value for the `display_type` field so that checking for downpayment doesn't rely on whether some other module is installed. --- Odoo PR: https://github.com/odoo/odoo/pull/246933 task-5871102
A recent error on the payment page when using Avatax with point of sale (POS) has been resolved. This was caused by an outdated method that no longer existed. The fix simply removed the problematic code, ensuring smooth payment processing.
Original PR description
Step to reproduce: - configure pos for Avatax from settings - open pos and settle a order - notice a error message on payment page Cause: - error is due to usage of `replaceDataByKey` which is removed in [1] [1] https://github.com/odoo/odoo/commit/3e94fe90ded58d498f0098cd9ed8679cbe500b8f Fix: - we removed the method as now we do not rely on it. opw-5089351 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/enterprise#106135 Forward-Port-Of: odoo/enterprise#102101