Daily updates from Odoo
Monday, February 9, 2026
7 changes · master
Resolved issues and error corrections
This update fixes an issue where the Kanban view for manufacturing orders was incorrectly displaying all active orders instead of those related to the selected operation type. The change was caused by a removal of a context key in the Odoo 19.0 release, leading to a domain filter that didn't properly restrict results. Now, the Kanban view accurately filters manufacturing orders by the chosen operation type.
Original PR description
**Steps to reproduce:** * Install the *stock_barcode_mrp* module. * Go to *Inventory* ‣ *Configuration* ‣ *Operation Types*. * Create two operation types with *Type of Operation* set to…
**Steps to reproduce:**
* Install the *stock_barcode_mrp* module.
* Go to *Inventory* ‣ *Configuration* ‣ *Operation Types*.
* Create two operation types with *Type of Operation* set to *Manufacturing*.
* Create two manufacturing orders.
* In each manufacturing order, under the *Miscellaneous* tab
set a different *Operation Type* created above.
* Ensure sufficient *On Hand Quantity* exists for a product used in manufacturing.
* Open the *Barcode* application.
* Open one of the created manufacturing operation types.
**Observed behavior:**
* The kanban view displays **all** manufacturing orders whose picking
types are active, instead of only those related to the selected operation type.
**Cause:**
* In 19.0, the context key *`'search_default_picking_type_id': self.id`* was removed
from `_get_action` function in this [commit](https://github.com/odoo/odoo/commit/9ed7109b8f11260084374f2d7fa7073a9ad3c240)
* Previously, this context value restricted results to the current picking type by default.
* The method `get_action_picking_tree_ready_kanban` in *stock_barcode_mrp*
now overrides the domain with only *`('picking_type_id.active', '=', True)`*.
* This domain checks that the picking type is active but does not filter by
the selected picking type, causing unrelated MOs to be shown.
**Fix:**
* This ensures only manufacturing orders belonging to
the selected operation type are displayed.
---
opw-5819358
Forward-Port-Of: odoo/enterprise#105327This 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
This update removes an unnecessary check within the expense approval process, simplifying the system. This change improves efficiency and reduces potential points of failure related to expense approvals. It addresses a technical detail that no longer impacts functionality.
Original PR description
This parameter has been removed since it was not needed anymore. task-4966942
This update resolves a technical issue affecting the accuracy of tests for the Gantt chart's popover closure functionality. By switching to a standard drag-and-drop method, the tests now reliably reflect the chart's behavior, ensuring consistent results. This improves the overall stability of the Gantt chart module.
Original PR description
This commit fixes the "close tooltip when drag pill" test by replacing the `dragPill` utility with a standard Hoot drag-and-drop action. The previous `dragPill` utility relied on the `contains(...).drag` helper, which artificially moved the element before initiating the drag. This behavior interfered with the specific conditions needed to test popover closure, making the standard drag approach more accurate for this scenario. runbot-error-238499
This update prevents the sale of products categorized as 'zero-price' through the website. It now allows businesses to select specific product categories where the Contact Us button will appear for these items, improving the user experience and ensuring accurate sales tracking. This change enhances data integrity and aligns with best practices.
Original PR description
- Added an option to choose specific product categories where the Contact Us button should appear for zero-priced items. - Updated naming from `prevent_zero_price_sale` to `prevent_sale` for logic and naming consistency. task-4819657 SEE ALSO: Upgrade PR: https://github.com/odoo/upgrade/pull/7928 Documentation PR:https://github.com/odoo/documentation/pull/13908 Community PR: https://github.com/odoo/odoo/pull/215526 Documentation PR(BY Documentation team): https://github.com/odoo/documentation/pull/15740