Wednesday, February 19, 2025
6 changes · saas-18.1
Resolved issues and error corrections
Fixes a problem where invoices created from the Point of Sale app could show errors when users reset, cancel, or confirm them. This prevents disruption in invoice corrections when no related sales order is present.
Original PR description
Currently, multiple errors occur when the user tries to edit the invoice created by the POS application. Steps to produce: - Install the `pos_sale` module. - Create a new order using the 'POS'…
Currently, multiple errors occur when the user tries to edit the invoice created by the POS application. Steps to produce: - Install the `pos_sale` module. - Create a new order using the 'POS' application (with invoice). - Open the corresponding invoice from `Invoicing > Customers > Invoices (list)`. - Click on the `Reset to Draft` button. - Click the `Cancel` button → encounter **Error-1**. - Click the `Confirm` button → encounter **Error-2**. **Error-1**: `TypeError - argument of type 'bool' is not iterable` **Error-2**: `AttributeError - 'bool' object has no attribute 'replace'` The issue occurs because `pos_order_line.sale_order_line_id.name` is accessed at [1], without verifying whether `sale_order_line_id` exists. [1] - https://github.com/odoo/odoo/blob/add64f4c8a8d7e3aeb324621da14fd9b0a3660c5/addons/pos_sale/models/account_move.py#L11-L15 This commit resolves the issue by ensuring the `sale_order_line_id` exists before accessing its attributes. If no sale order is defined, the method skips further computation to prevent errors. sentry-6272400381, 6272399674 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
The Chart of Accounts sidebar now correctly shows account group codes again. This fixes a display issue caused by a framework behavior change, helping accounting users navigate account groups as expected.
Original PR description
The Chart of Accounts sidebar does not display account group codes due to the limit being set to `0`. In earlier versions, `limit="0"` was used to indicate no limit at all, as the default value…
The Chart of Accounts sidebar does not display account group codes due to the limit being set to `0`. In earlier versions, `limit="0"` was used to indicate no limit at all, as the default value (`200`) was not sufficient. However, in version 18.1, a change in the Odoo framework introduced a stricter limit check in this [commit](https://github.com/odoo/odoo/blob/88dff02bae41ff794ac3e60acab061acfc8e19ca/odoo/orm/models.py#L5596-L5597). With this update, `limit=0` is now interpreted as a **hard limit of zero records**, meaning nothing is retrieved from the dataset. As a result, account groups no longer appear in the sidebar. Previously, `limit="0"` would effectively disable any limit. To achieve the same behavior in 18.1+, `limit` must be explicitly set to `False` or `None`. Steps to Reproduce: 1. Navigate to Accounting → Configurations → Chart of Accounts. 2. Observe that the account group codes are missing from the sidebar. opw-4538769 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This corrects how Odoo searches records when filters include both no linked record and specific linked records. It prevents incorrect search results in business workflows that rely on these relationship filters, while adding tests to guard the behavior.
Original PR description
The logic for the generated SQL for x2many fields is incorrect when we have both False and values in `in` conditons for x2many fields. We must do 2 sub-queries in that case. For example, in `[1, False]` means we do not have any records in the comodel or we `1` is linked to the model through the relation. We could do it in one-subquery, group by the model's id and filter using a having condition `COUNT(CASE ...)`, but that would complexity the code for an edge case. The basic case, where we have just False in the values, still inverses the existance condition and searches the whole comodel. odoo/enterprise#79593 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Sales commission reporting now uses only posted invoices, handles refunds correctly, and includes subscription recurring revenue details when appropriate. Adjustments are tied to a single commission target to prevent double counting, and multi-company achievements are converted into the current company currency for clearer reporting.
Original PR description
taskid : 4471762
This fix prevents users from accidentally editing Knowledge embedded view filters in a way that could create unwanted records. It also preserves favorite filters when views are inserted into Knowledge articles, helping users keep their saved filtering preferences intact.
Original PR description
### **This commit fixes two issues introduced by [cdf65f563e6](https://github.com/odoo/odoo/pull/185954/commits/cdf65f563e6dc09ca238395e480da095232ac044):** **1. Edit action incorrectly enabled for…
### **This commit fixes two issues introduced by [cdf65f563e6](https://github.com/odoo/odoo/pull/185954/commits/cdf65f563e6dc09ca238395e480da095232ac044):** **1. Edit action incorrectly enabled for knowledge embedded view filters** - These filters are not linked to server records in Knowledge - Attempting to edit leads to unwanted filter record creation - Should use delete action instead of edit for these cases **2. Favorites being lost in embedded views due to reconciliation** - `_reconciliateFavorites` deletes SearchItems that can't be reconciled - Embedded view filters are dissociated from record values - Results in loss of favorite filters when inserting views ### Solution: - Override `_reconciliateFavorites` to skip reconciliation for embedded views - Override `web.SearchBarMenu.FavoriteItem` to: * Restore delete action for embedded view filters * Add proper title and icon * Reimplement `openConfirmationDialog` flow by patching `SearchBarMenu` - Reintroduce `deleteFavorite` in KnowledgeSearchModelMixin ### Reproduce Steps: **1st issue:** Create embedded view with "/kanban" or insert from another module - Add filter > edit action is present **2nd Issue :** In any module - Add favorite filter - Insert view into Knowledge article - Filter is missing opw-4518370
Planning records without roles are no longer incorrectly included when filtering out empty role assignments. This keeps planning results aligned with the intended business rules and avoids showing irrelevant records.
Original PR description
Impact on enterprise. We do not want to get records that don't have any roles as before the fix, False was ignored in x2m fields. odoo/odoo#197890