Friday, May 2, 2025
16 changes · saas-18.3
Resolved issues and error corrections
The stock module now correctly uses the standard serial and lot number sequence when no custom prefix is provided. This prevents missing or disabled numbering setup for products that rely on default lot or serial tracking.
Original PR description
This commit fixes setting the default sequence for serials/lots introduced in #200395. Previously, the sequence was set to False when the custom prefix is empty. Now it falls back to the default serials sequence defined in the module data. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Miscellaneous changes
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595 Forward-Port-Of: odoo/odoo#207264 Forward-Port-Of: odoo/odoo#206985
Original PR description
This fix just add the error code and error message for IT language. Ref: odoo/odoo#184156 Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4728595) opw-4728595 Forward-Port-Of: odoo/odoo#207264 Forward-Port-Of: odoo/odoo#206985
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
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
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
In this commit, we're refactoring macro.js by completely changing its operation. To detect triggers in the DOM, we no longer rely on DOM mutations, but instead check for each frame to see if the trigger is in the DOM. Once the trigger is found, we perform the action and move on to the next step. This significantly simplifies understanding of how macro.js works, tours, and, more importantly, the bugs that can occur in tours. This also avoids many indeterministic errors that could occur in
Original PR description
In this commit, we're refactoring macro.js by completely changing its operation. To detect triggers in the DOM, we no longer rely on DOM mutations, but instead check for each frame to see if the trigger is in the DOM. Once the trigger is found, we perform the action and move on to the next step. This significantly simplifies understanding of how macro.js works, tours, and, more importantly, the bugs that can occur in tours. This also avoids many indeterministic errors that could occur in the tours due to the completely arbitrary "checkDelay" parameter (the time period after which there are no more mutations before the element is checked to see if it is in the DOM). This checkDelay parameter is therefore no longer used. It will be completely removed from the codebase in a future PR. Forward-Port-Of: odoo/odoo#205936 Forward-Port-Of: odoo/odoo#194508
When selling a physical gift card, and invoicing it. The code and partner id where not taken into account. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on selling a physical gift card * Enter any code * Validate the order and invoice it > Observation: If you check the gift card in the backend, you will see that the code and partner id are not set correctly. Why the fix: ------------ When updating the rewards, the code and partner id
Original PR description
When selling a physical gift card, and invoicing it. The code and partner id where not taken into account. Steps to reproduce: ------------------- * Open PoS * Add a gift card to the order * Click on selling a physical gift card * Enter any code * Validate the order and invoice it > Observation: If you check the gift card in the backend, you will see that the code and partner id are not set correctly. Why the fix: ------------ When updating the rewards, the code and partner id were never set. opw-4597330 Forward-Port-Of: odoo/odoo#207322 Forward-Port-Of: odoo/odoo#206071
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
### 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
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
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
We never took the 'cumulated_start' option of an Odoo chart into account and instead relied on 'cumulative' but the options are not linked neither one implied by the other. Task-4701303 Forward-Port-Of: odoo/enterprise#84515 Forward-Port-Of: odoo/enterprise#82954
Original PR description
We never took the 'cumulated_start' option of an Odoo chart into account and instead relied on 'cumulative' but the options are not linked neither one implied by the other. Task-4701303 Forward-Port-Of: odoo/enterprise#84515 Forward-Port-Of: odoo/enterprise#82954
In this commit, we prefer to use click on element instead of press Tab because tab will directly focus the other range period input. Forward-Port-Of: odoo/enterprise#83395 Forward-Port-Of: odoo/enterprise#82937
Original PR description
In this commit, we prefer to use click on element instead of press Tab because tab will directly focus the other range period input. Forward-Port-Of: odoo/enterprise#83395 Forward-Port-Of: odoo/enterprise#82937
**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- Since this PR: https://github.com/odoo/enterprise/pull/82531, the "Customer Statement" smart button (inside the customer form) was no longer visible when orders were paid via customer accounts in PoS and the session was closed. This was caused by session-level account.move records lacking partner_id, which caused _compute_has_moves to return false. - This fix overrides `_compute_has_moves` inside the module `pos_settle_due` to set `has_moves` to True when a partner's total_due is non-zero, en
Original PR description
- Since this PR: https://github.com/odoo/enterprise/pull/82531, the "Customer Statement" smart button (inside the customer form) was no longer visible when orders were paid via customer accounts in PoS and the session was closed. This was caused by session-level account.move records lacking partner_id, which caused _compute_has_moves to return false. - This fix overrides `_compute_has_moves` inside the module `pos_settle_due` to set `has_moves` to True when a partner's total_due is non-zero, ensuring the statement button remains visible when relevant. task-id: 4749148 Forward-Port-Of: odoo/enterprise#84206 Forward-Port-Of: odoo/enterprise#84003
### 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