Daily updates from Odoo
Friday, May 2, 2025
21 changes
14 changes
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
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
7 changes
Resolved issues and error corrections
The contract salary workflow no longer shows a "partially signed" status when a contract template only requires one signature. This avoids confusion for HR teams and employees by showing a more accurate contract status.
Original PR description
- displaying a "partially signed" state in the contract state even when the contract PDF template requires only one signature. Task: 4592653
Miscellaneous changes
Added required checks for generic annual closing return type. task-4627315 Forward-Port-Of: odoo/enterprise#84412
Original PR description
Added required checks for generic annual closing return type. task-4627315 Forward-Port-Of: odoo/enterprise#84412
task-4627315 Forward-Port-Of: odoo/enterprise#84426
Original PR description
task-4627315 Forward-Port-Of: odoo/enterprise#84426
Forward-Port-Of: odoo/enterprise#84391
Original PR description
Forward-Port-Of: odoo/enterprise#84391
**Traceback:** ```python ('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157): Traceback (most recent call last): File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu self.mock_action(action_vals) File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action return self.mock_act_window(action) File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in moc
Original PR description
**Traceback:** ```python ('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157): Traceback (most recent call last): File…
**Traceback:**
```python
('helpdesk.helpdesk_ticket_menu_all', 117, 'Helpdesk > Tickets > All Tickets', 157):
Traceback (most recent call last):
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 259, in crawl_menu
self.mock_action(action_vals)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 272, in mock_action
return self.mock_act_window(action)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 432, in mock_act_window
mock_method(model, view, fields_list, domain, group_by)
File "/tmp/tmpbeh7fp2m/migrations/base/tests/test_mock_crawl.py", line 463, in mock_view_form
[data] = record.read(fields_list)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 3814, in read
return self._read_format(fnames=fields, load=load)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4045, in _read_format
vals[name] = convert(record[name], record, use_display_name)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 7031, in __getitem__
return self._fields[key].__get__(self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1303, in __get__
self.compute_value(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1485, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/18.0/addons/base_automation/models/base_automation.py", line 816, in _compute_field_value
return _compute_field_value.origin(self, field)
File "/home/odoo/src/odoo/18.0/addons/mail/models/mail_thread.py", line 429, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 5253, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 110, in determine
return needle(*args)
File "/home/odoo/src/enterprise/18.0/helpdesk/models/helpdesk_ticket.py", line 298, in _compute_partner_ticket_count
partner_tickets.fetch(['stage_id']) # prevent over-fetching fields, leading to potential out-of-memory error
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4095, in fetch
self.check_access('read')
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4394, in check_access
if not self.env.su and (result := self._check_access(operation)):
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4435, in _check_access
if domain and (forbidden := self - self.sudo().filtered_domain(domain)):
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6627, in filtered_domain
data = record.mapped(key)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 6470, in mapped
recs = recs._fields[name].mapped(recs)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1377, in mapped
self.__get__(first(remaining))
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 3059, in __get__
return super().__get__(records, owner)
File "/home/odoo/src/odoo/18.0/odoo/fields.py", line 1266, in __get__
recs._fetch_field(self)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4071, in _fetch_field
self.fetch(fnames)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4108, in fetch
fetched = self._fetch_query(query, fields_to_fetch)
File "/home/odoo/src/odoo/18.0/odoo/models.py", line 4197, in _fetch_query
rows = self.env.execute_query(query.select(*sql_terms))
File "/home/odoo/src/odoo/18.0/odoo/api.py", line 979, in execute_query
return [] if self.cr.description is None else self.cr.fetchall()
MemoryError
```
Issue:
------
The `_compute_partner_ticket_count` method caused a MemoryError while running the test cases due to the large number of records and over fetching of `stage_id` in the line: `partner_tickets.fetch(['stage_id'])`
followed by: `partner_tickets.filtered(lambda ticket: not ticket.stage_id.fold)`
Solution:
---------
Replaced the fetch and filtered logic with a search method to resolve the MemoryError and improve performance
upg-2707381
opw-4653413
Forward-Port-Of: odoo/enterprise#83280- and changed report type and selections' string task-4720586 Forward-Port-Of: odoo/enterprise#83352
Original PR description
- and changed report type and selections' string task-4720586 Forward-Port-Of: odoo/enterprise#83352
### Issue: - In attendance-based contracts, lunch break intervals were automatically deducted from attendances,. - However, this deduction was not reflected in the generated work entries, resulting in inconsistencies between attendance duration and payroll calculations. ### Steps To Repoduce: - Set up an attendance-based contract with lunch break in the schedule. - Log attendance from 08:00 to 20:00 without logging out for lunch. - Observe: - The attendance has the lunch b
Original PR description
### Issue:
- In attendance-based contracts, lunch break intervals were automatically deducted from attendances,.
- However, this deduction was not reflected in the generated work entries, resulting in inconsistencies
between attendance duration and payroll calculations.
### Steps To Repoduce:
- Set up an attendance-based contract with lunch break in the schedule.
- Log attendance from 08:00 to 20:00 without logging out for lunch.
- Observe:
- The attendance has the lunch break interval deducted.
- The work entry does not, and includes the full duration.
### Solution:
- revert the change introduced in https://github.com/odoo/enterprise/pull/71979/commits/0a54ef993da3ef4882acdee1b8f5e378e2e9f2e0 only for contracts without flexible hours.
- Lunch breaks are now deducted from both attendances and work entries only when the contract has flexible_hours = False.
opw-4627247
Forward-Port-Of: odoo/enterprise#83825