Daily updates from Odoo
Friday, May 2, 2025
16 changes · saas-18.2
Resolved issues and error corrections
This update improves how the point-of-sale payment screen handles removable zero-quantity order lines, reducing the chance of incorrect cleanup during due settlement. It also streamlines related automated test steps so future changes can be validated more consistently.
Original PR description
- Introduced `canBeRemoved` property in `PosOrderline` to simplify zero-qty line removal logic. - Updated payment screen to use `canBeRemoved` for cleaner filtering. - Added reusable tour helpers: `clickDropDownItemText` and `clickSettleOrderName`. See also: odoo/enterprise#84117 Task [link](https://www.odoo.com/odoo/project/967/tasks/4751971) task-4751971
This update brings the spreadsheet component to its latest maintenance version, fixing several issues around charts, pivot tables, formatting, range deletion, frozen rows, and collaborative editing. Users should see more reliable spreadsheet behavior, better chart exports and display quality, and fewer unnecessary refreshes during everyday use.
Original PR description
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e8ff3fc46 [REL] 18.2.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)…
### Contains the following commits: https://github.com/odoo/o-spreadsheet/commit/e8ff3fc46 [REL] 18.2.10 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/e6e60cb10 [FIX] selection_input: fix range deletion [](https://www.odoo.com/odoo/2328/tasks/) https://github.com/odoo/o-spreadsheet/commit/fbccf06de [FIX] chart: avoid useless chart update [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/ad0c3ed69 [FIX] Pivot: allowDispatch invalid pivot dataset [Task: 4756759](https://www.odoo.com/odoo/2328/tasks/4756759) https://github.com/odoo/o-spreadsheet/commit/49d8d1d8e [FIX] bottom_bar_statistic: react to change in cell format [Task: 4747031](https://www.odoo.com/odoo/2328/tasks/4747031) https://github.com/odoo/o-spreadsheet/commit/bc597f95f [FIX] tables: react to change in cell format [Task: 4747031](https://www.odoo.com/odoo/2328/tasks/4747031) https://github.com/odoo/o-spreadsheet/commit/4c52b80a0 [FIX] header_overlay: restore row/col move preview [Task: 4747268](https://www.odoo.com/odoo/2328/tasks/4747268) https://github.com/odoo/o-spreadsheet/commit/5c9479c2e [FIX] xlsx: correctly export aggregated charts [Task: 4714410](https://www.odoo.com/odoo/2328/tasks/4714410) https://github.com/odoo/o-spreadsheet/commit/a280ac312 [IMP] sheetview: lazily re-compute viewports on freeze rows [Task: 3600662](https://www.odoo.com/odoo/2328/tasks/3600662) https://github.com/odoo/o-spreadsheet/commit/660057e76 [FIX] ChartRuntime: take devicePixelRatio in account [Task: 4661712](https://www.odoo.com/odoo/2328/tasks/4661712) https://github.com/odoo/o-spreadsheet/commit/8f373cc54 [FIX] chart: ignore trendline datasets in show values plugin [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/7e19305a1 [FIX] chart: align moving average trendline with bar chart offset [Task: 4653065](https://www.odoo.com/odoo/2328/tasks/4653065) https://github.com/odoo/o-spreadsheet/commit/3ca421fd7 [FIX] package: saas-18.2 is no longer the latest version [Task: 0](https://www.odoo.com/odoo/2328/tasks/0) https://github.com/odoo/o-spreadsheet/commit/f81be368b [FIX] grid_overlay: stop interval on error [Task: 4746478](https://www.odoo.com/odoo/2328/tasks/4746478) https://github.com/odoo/o-spreadsheet/commit/42518534e [FIX] Collaborative: Send client position on activeSheet change [Task: 4736980](https://www.odoo.com/odoo/2328/tasks/4736980) Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com> Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com> Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com> Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com> Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com> Co-authored-by: Mehdi Rachico (mera) <mera@odoo.com> Co-authored-by: Florian Damhaut (flda) <flda@odoo.com> Co-authored-by: Rémi Rahir (rar) <rar@odoo.com> Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com> Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Fixed an issue that caused an error when users selected multiple posted customer invoices and used Send and Print from the list view. The change ensures the process uses the correct invoice records, allowing batch invoice sending to complete reliably.
Original PR description
Currently, a traceback is occurring when the user tries to send and print invoices in batch. <b>To reproduce this issue:</b> 1) Open the customer invoices list view in Accounting 2) Select multiple posted invoices and click send <b>Error:- </b> ``` KeyError: <NewId origin=2125> ``` <b>Cause:</b> The issue arises because the wizard record has not been saved, resulting in an issue in returning the origin id for move while computing the `_compute_alerts` method. This leads to the traceback from the below line because self.id origin id in this case. https://github.com/odoo/odoo/blob/255a612a63be883bf9b73fff1bca4f66db430091/addons/mail/models/mail_thread.py#L1953-L1955 <b>Solution:-</b> Instead of passing the record with origin id, we can pass the actual move record. opw-4750394
Miscellaneous changes
The option of "cumulatedStart" was incorrectly infered from the "cumulative" option of an Odoo graph view. However, both options are not specifically linked. Task-4701303 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208112 Forward-Port-Of: odoo/odoo#204980
Original PR description
The option of "cumulatedStart" was incorrectly infered from the "cumulative" option of an Odoo graph view. However, both options are not specifically linked. Task-4701303 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208112 Forward-Port-Of: odoo/odoo#204980
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue ----- No delivery address is registered, making the merchant ineligible for seller protection. Cause ----- Commit 00259dc44a981 added the `no_shipping: '1'` value to the form sent to Paypal to prevent buyers from changing their shipping address on Paypal's end. A side-effect is t
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue…
Versions -------- - 16.0+ Steps ----- 1. Enable Paypal as payment provider; 2. have a US-based partner; 3. sent them a payment link; 4. pay using Paypal; 5. open transaction on Paypal backend. Issue ----- No delivery address is registered, making the merchant ineligible for seller protection. Cause ----- Commit 00259dc44a981 added the `no_shipping: '1'` value to the form sent to Paypal to prevent buyers from changing their shipping address on Paypal's end. A side-effect is that it doesn't even register the address provided with the transaction. Solution (16.0 up to saas-17.4) ------------------------------- Use the `address_override: '1'` value instead, which prevents buyers from changing the address while still registering the address on the transaction. In stable, keep the `no_shipping: '1'` value in the rendering values so that user's cannot suddenly change the address again if template hasn't been updated yet. Solution (18.0+) ---------------- Change the `shipping_preference` value from `NO_SHIPPING` to `SET_PROVIDED_ADDRESS`[^1]. opw-4681336 [^1]: https://developer.paypal.com/docs/checkout/standard/customize/shipping-module/#:~:text=Configuring%20shipping%20preferences Forward-Port-Of: odoo/odoo#205972 Forward-Port-Of: odoo/odoo#205686
Sale status was not correctly set when ticket where sold from the POS. Steps to reproduce: ------------------- * Create an event and make sure ticket can be sold in PoS * Open PoS * Add a ticket to the order and complete the order * Add another ticket to the order but go to the backend to save it as draft > Observation: The sale status of the order appears as 'free' when it should be "Sold" and "Not Sold" Why the fix: ------------ We make sure to take the state of the PoS order
Original PR description
Sale status was not correctly set when ticket where sold from the POS. Steps to reproduce: ------------------- * Create an event and make sure ticket can be sold in PoS * Open PoS * Add a ticket to the order and complete the order * Add another ticket to the order but go to the backend to save it as draft > Observation: The sale status of the order appears as 'free' when it should be "Sold" and "Not Sold" Why the fix: ------------ We make sure to take the state of the PoS order when the ticket has been sold through the PoS. opw-4584390 Forward-Port-Of: odoo/odoo#208026 Forward-Port-Of: odoo/odoo#204514
To reproduce the issue: 1. In Settings, enable: - Storage Locations - Units of Measure & Packagings - Packages 2. In uom list, edit Pack of 6: - Package type: Pallet 3. Create a putaway rules: - From: WH/Stock - Package type: Pallet - To: WH/Stock/Shelf 1 4. Create and confirm a receipt with one Pack of 6 of any product Error: in the detailed operations of the SM, the destination location is still WH/Stock. It should be the shelf. A small mistake happened d
Original PR description
To reproduce the issue: 1. In Settings, enable: - Storage Locations - Units of Measure & Packagings - Packages 2. In uom list, edit Pack of 6: - Package type: Pallet 3. Create a putaway rules: - From: WH/Stock - Package type: Pallet - To: WH/Stock/Shelf 1 4. Create and confirm a receipt with one Pack of 6 of any product Error: in the detailed operations of the SM, the destination location is still WH/Stock. It should be the shelf. A small mistake happened during the big refactoring of UoM and packaging: commit [1] simply removed the use of the SM's packaging instead of using the new field [1] https://github.com/odoo/odoo/commit/dc24a1d1c93cf6eeb6456b1591a0ab8ccc4086ba OPW-4750639 Forward-Port-Of: odoo/odoo#208137
When an orderline is deleted, it wasn't being removed from the indexedDB. This commit ensures that deleted orderlines are also removed from the local storage, maintaining data integrity in the POS. opw-4626344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202110
Original PR description
When an orderline is deleted, it wasn't being removed from the indexedDB. This commit ensures that deleted orderlines are also removed from the local storage, maintaining data integrity in the POS. opw-4626344 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#202110
Versions -------- - 17.0+ Steps ----- 1. Create a product with 3 attributes; 2. add a never-create multi-select attribute; 3. archive the first two variants; 4. publish the product to eCommerce; 5. open /shop. Issue ----- > 500: Internal Server Error Cause ----- Commit 30994723e9ee5 updated the `_cartesian_product` method to handle `multi`-type attributes. When these are on the last attribute line, the method will yield the current partial combination. Issue is when conti
Original PR description
Versions -------- - 17.0+ Steps ----- 1. Create a product with 3 attributes; 2. add a never-create multi-select attribute; 3. archive the first two variants; 4. publish the product to eCommerce; 5.…
Versions -------- - 17.0+ Steps ----- 1. Create a product with 3 attributes; 2. add a never-create multi-select attribute; 3. archive the first two variants; 4. publish the product to eCommerce; 5. open /shop. Issue ----- > 500: Internal Server Error Cause ----- Commit 30994723e9ee5 updated the `_cartesian_product` method to handle `multi`-type attributes. When these are on the last attribute line, the method will yield the current partial combination. Issue is when continuing after the `yield`, it attempts to get the `current_ptav_index` from the `current_line_values` recordset, which is empty for `multi`-type attributes. This causes an `IndexError`. Solution -------- Only assign the `current_ptav` variable if `current_line_values` is not falsey, i.e. isn't on a `multi` attribute line. Because `current_ptav_index` will always be `-1` in this scenario, it will skip over the conditional branches where `current_ptav` gets used, and instead go to either `continue` or `break`. opw-4653696 Forward-Port-Of: odoo/odoo#203093
This commit fixes wrongly used `isMobileOs` in attachment list. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208232
Original PR description
This commit fixes wrongly used `isMobileOs` in attachment list. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#208232
When calculating earnings-based withholdings in company-branch setups, the logic incorrectly referenced accounting entries from the mother company if the user belonged to a branch. This led to incorrect accumulation of taxable base amounts and previously withheld amounts, especially when vendor bills or payments were made in a branch. This fix ensures that: - The accumulation logic in `_tax_compute_all_helper` correctly scopes move line searches using the user's company. As a result, with
Original PR description
When calculating earnings-based withholdings in company-branch setups, the logic incorrectly referenced accounting entries from the mother company if the user belonged to a branch. This led to incorrect accumulation of taxable base amounts and previously withheld amounts, especially when vendor bills or payments were made in a branch. This fix ensures that: - The accumulation logic in `_tax_compute_all_helper` correctly scopes move line searches using the user's company. As a result, withholding retention now behaves correctly in company-branch environments. opw-4581579 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203246
If a plan B has sub plans (C1, C2) already with analytics entries, and then plan B is updated to also have a parent plan A, hence the structure would be A/B/C1 and A/B/C2, the Analytic entries data on the sub plans is cleared off from C1 and C2. opw-4338406 Forward-Port-Of: odoo/odoo#207797
Original PR description
If a plan B has sub plans (C1, C2) already with analytics entries, and then plan B is updated to also have a parent plan A, hence the structure would be A/B/C1 and A/B/C2, the Analytic entries data on the sub plans is cleared off from C1 and C2. opw-4338406 Forward-Port-Of: odoo/odoo#207797
Steps: - Compare 2 views Actual result: - Header text color is dark with dark background  Expected result: - Header text color is light with dark background  Forward-Port-Of: odoo/odoo#206044
Original PR description
Steps: - Compare 2 views Actual result: - Header text color is dark with dark background  Expected result: - Header text color is light with dark background  Forward-Port-Of: odoo/odoo#206044
- In this PR (https://github.com/odoo/odoo/pull/199923) we set a default system parameter to define the number limit of partner to load in PoS by default (set to 20000). - But since this PR (https://github.com/odoo/odoo/pull/184417) the default value was was changes from 20000 to 5000. - To avoid making new similar issues, these defaults values are now extracted as constant class. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR
Original PR description
- In this PR (https://github.com/odoo/odoo/pull/199923) we set a default system parameter to define the number limit of partner to load in PoS by default (set to 20000). - But since this PR (https://github.com/odoo/odoo/pull/184417) the default value was was changes from 20000 to 5000. - To avoid making new similar issues, these defaults values are now extracted as constant class. Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged: --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#203432
In this version, the picking type code `dropship` has been introduced to differentiate incoming types from this one (ref: 1547d66585a4b57cd3b747f28b7514dbd9d7bef8), but the search for missing companies without this new type is still being done with the old criteria of the source and target location. Let's change this to use the new picking type code. @Tecnativa Forward-Port-Of: odoo/odoo#201968
Original PR description
In this version, the picking type code `dropship` has been introduced to differentiate incoming types from this one (ref: 1547d66585a4b57cd3b747f28b7514dbd9d7bef8), but the search for missing companies without this new type is still being done with the old criteria of the source and target location. Let's change this to use the new picking type code. @Tecnativa Forward-Port-Of: odoo/odoo#201968
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves
Original PR description
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of…
### Steps to reproduce: - In the settings enable Multi-Step routes - Unarchive the MTO route - Create a storable product using the MTO and buy route - Create and confirm a sale order for 100 units of that product - Validate the delivery for only 30 units and backorder the rest #### > The purchase order demand was updated to 170 units ### Cause of the issue: Since the refactoring a72382063ee662010729d983fbf6fb6305b8adf2 the rule of the MTO route is purely MTO. Furthermore, the moves creating and running a procurement are added depending solely on their `procure_method` during the `_action_confirm`: https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1485-L1496 https://github.com/odoo/odoo/blob/1dd360658222c0afeb268a5c8cf435defddf55d1/addons/stock/models/stock_move.py#L1503-L1513 In our use case, the delivery move is therefore created as `mto` and then creates and run a procurments creating the PO during its confirmation. However, when it is backordered, the backorder move is also created and confirmed as `mto` by the `_create_backorder` call: https://github.com/odoo/odoo/blob/02a370a7a34a42f2bc9f668eee756fb466db8722/addons/stock/models/stock_move.py#L2071-L2075 It will therefore also automatically create and run a procurment that will in turn modify the current PO. opw-4633920 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205192