Friday, April 18, 2025
18 changes · 17.0
New functionality added to Odoo
Adds automated test coverage to ensure vendor bills can be auto-completed from purchase orders using foreign currency, taxes, and payment terms when inventory purchasing is enabled. This helps prevent a past error that could block users from creating bills after receiving goods.
Original PR description
The issue was introduced by: https://github.com/odoo/odoo/commit/90158f647ba610b31499555641c9db8450b49c4c The issue has been fixed by:…
The issue was introduced by: https://github.com/odoo/odoo/commit/90158f647ba610b31499555641c9db8450b49c4c The issue has been fixed by: https://github.com/odoo/odoo/commit/b1666c61bbc9d7e7b920483e168c6048ecde011c This commit is adding a test for it. **Steps to reproduce:** - Install Accounting and purchase_stock - Activate a foreign currency (e.g. Euro) - Create a PO: * Vendor: [any] * Currency: EUR * Product: [any with a Unit Price and a tax] * Payment Terms: [any] (e.g. 15 Days) - Confirm the PO - Validate the receipt order - Go to "Accounting / Vendors / Bills" - Create a new bill - In "Auto-Complete" field, select the created PO **Issue:** A traceback is raised due to a division by zero. **Cause:** The bill and its lines are created from some information coming from the PO. In the computation of the needed terms of the bill, a computation of the taxes is called on the lines (i.e. _compute_all_tax). During that computation, the rate is computed as followed: (*) rate = line.amount_currency / line.balance if line.balance else line.currency_rate and later, rate is used as followed: 'balance': tax['amount'] / rate When "purchase_stock" module is not installed, there is no issue because "_prepare_account_move_line" method from "purchase.order. line" model doesn't initialized "amount_currency" nor "balance". Therefore, the result of (*) falls back on "line.currency_rate" which is not zero. However, when "purchase_stock" module is installed, "balance" is initialized in "_prepare_account_move_line" but not "amount_currency", leading a result of 0 for (*). opw-4681735
Resolved issues and error corrections
Partner autocomplete now handles cases where GST lookup returns no company details instead of failing. This prevents users from being blocked by an error when a GST number has no enrichment data available.
Original PR description
This happened because the Partner Autocomplete service was returning an empty response for this particular GST number and the code was assuming that the name was always present. Sentry - 6327760196
Miscellaneous changes
Versions -------- - 16.0 - 17.0 - saas-17.4 used API changed starting from 18.0 Steps ----- 1. Set up PayPal; 2. have a partner with no address; 3. send a payment link to the partner; 4. attempt to pay using PayPal. Issue ----- > There's a problem with your shipping address. Cause ----- Commit 449b62d129f1 changed the `no_shipping` value in the form data to `address_override` to prevent users from changing their shipping address without losing seller protection. Issue
Original PR description
Versions -------- - 16.0 - 17.0 - saas-17.4 used API changed starting from 18.0 Steps ----- 1. Set up PayPal; 2. have a partner with no address; 3. send a payment link to the partner; 4. attempt to pay using PayPal. Issue ----- > There's a problem with your shipping address. Cause ----- Commit 449b62d129f1 changed the `no_shipping` value in the form data to `address_override` to prevent users from changing their shipping address without losing seller protection. Issues is that if `address_override` is set, PayPal expects a shipping address to be given, which isn't always possible. Solution -------- If the partner has no valid shipping address, leave `no_shipping` on `1`, and set `address_override` to `0`. opw-4681336 Forward-Port-Of: odoo/odoo#206455
This update corrects an automated test for Italian delivery documents so it uses the right permissions when creating a sales order. It helps keep quality checks reliable and prevents false failures during development.
Original PR description
`TestItEdiDDT.test_deferred_invoice` creates a sales order but does not ensure the user has the rights to create one. https://runbot.odoo.com/odoo/error/163639
Fixes an issue where website popups configured to reappear after a short delay could stay hidden indefinitely for visitors. The change ensures the popup delay is saved correctly by browsers, so campaigns and notices appear again at the intended time.
Original PR description
Steps to reproduce the issue: - Add a popup with a 0.0001 days config. - Visit the page as a non-connected user. - The popup opens at some point. - Close the popup. - Wait 10 seconds. - Refresh the…
Steps to reproduce the issue: - Add a popup with a 0.0001 days config. - Visit the page as a non-connected user. - The popup opens at some point. - Close the popup. - Wait 10 seconds. - Refresh the page ---> The popup never reappears. This issue comes from the fact that we were setting a non-integer value for the cookie expiration. The "max-age" attribute does not accept float values, so the cookie is treated as a "session" cookie. It only expires when the session ends, which can be effectively "never" on some browsers that keep sessions open indefinitely. This used to work before commit [1] because we were also setting an "expires" attribute. When the "max-age" attribute was invalid, the browser would fallback to the "expires" attribute. Since that commit removed the "expires" attribute, the only remaining value (max-age) is invalid, and the popup never reappears as expected. This fix ensures the value used in "max-age" is always an integer, avoiding any invalid cookie behavior. [1]: https://github.com/odoo/odoo/commit/006ee1fc470eabdcbde68077259cf543633d6490 task-4690318
Service products now honor the unit of measure defaults configured by users when the Timesheets on Sales module is installed. This prevents products from being automatically set to hours when the business has chosen a different default unit.
Original PR description
**Issue:** When User-defined Defaults are set for Unit of Measure (product.template or product.product) and sale_timesheet module is installed, the uom default is not respected. **Steps to reproduce:** - ensure sale_timesheet module is installed - settings > technical > user-defined Defaults - create a default for unit of measure (product.template) other than hour - create a new product of type service The issue occurs in both product.template and product.product opw-4604491
This fixes an error that could occur in Point of Sale manufacturing tests when setting up bills of materials without product variants enabled. The change avoids using a hidden product variant field, making setup more reliable without changing business functionality.
Original PR description
Similar to #206050, sale_mrp has a bunch of forms which try to set the `product_id` on a bom without product variants being enabled, in which case the field is invisible and setting it fails. Since they don't seem to really care for variants, and the products are not created with variants, as in #206050 just don't set `product_id`. https://runbot.odoo.com/odoo/error/163112
This update stops unnecessary warning messages from filling IoT Box logs when harmless message types are received. It makes logs easier to review and helps teams focus on issues that actually need attention.
Original PR description
Currently the IoT Box are being infested with logs like `2025-04-17 11:30:46,925 13649 WARNING ? odoo.addons.hw_drivers.websocket_client: message type not supported: bundle_changed` This PR removes them as they aren't useful information task-4735615
Fixes a crash that could occur when a spreadsheet attachment has missing or empty stored data, such as during upgrades without the original file storage. This helps keep document and spreadsheet records usable and avoids background processing failures.
Original PR description
Steps to reproduce: 1. Install documents module with demo data 2. After this navigate Settings -> Technical -> Database Structure -> Attachments 4. In attachment delete the spreadsheet(Partner…
Steps to reproduce:
1. Install documents module with demo data
2. After this navigate Settings -> Technical -> Database Structure
-> Attachments
4. In attachment delete the spreadsheet(Partner Spreadsheet Test)
from file content and try to save it will raise below mentioned
traceback will raise
Why following this flow -> during upgrade don't have the filestore so there is possiblity spreadsheet_data would be empty and traceback can raise.
that is why handling this:
```
Traceback (most recent call last):
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_autovacuum.py", line 39, in _run_vacuum_cleaner
self.env.cr.commit()
File "/home/odoo/src/odoo/odoo/sql_db.py", line 472, in commit
self.flush()
File "/home/odoo/src/odoo/odoo/sql_db.py", line 137, in flush
self.transaction.flush()
File "/home/odoo/src/odoo/odoo/api.py", line 879, in flush
env_to_flush.flush_all()
File "/home/odoo/src/odoo/odoo/api.py", line 737, in flush_all
self._recompute_all()
File "/home/odoo/src/odoo/odoo/api.py", line 733, in _recompute_all
self[field.model_name]._recompute_field(field)
File "/home/odoo/src/odoo/odoo/models.py", line 6978, in _recompute_field
field.recompute(records)
File "/home/odoo/src/odoo/odoo/fields.py", line 1379, in recompute
apply_except_missing(self.compute_value, recs)
File "/home/odoo/src/odoo/odoo/fields.py", line 1352, in apply_except_missing
func(records)
File "/home/odoo/src/odoo/odoo/fields.py", line 1401, in compute_value
records._compute_field_value(self)
File "/home/odoo/src/odoo/addons/mail/models/mail_thread.py", line 424, in _compute_field_value
return super()._compute_field_value(field)
File "/home/odoo/src/odoo/odoo/models.py", line 4924, in _compute_field_value
fields.determine(field.compute, self)
File "/home/odoo/src/odoo/odoo/fields.py", line 102, in determine
return needle(*args)
File "/home/odoo/src/enterprise/documents/models/documents_document.py", line 149, in _compute_is_multipage
document.is_multipage = bool(document._get_is_multipage()) # None => False
File "/home/odoo/src/enterprise/documents_spreadsheet/models/documents_document.py", line 256, in _get_is_multipage
spreadsheet_data = json.loads(self.spreadsheet_data)
File "/usr/lib/python3.10/json/__init__.py", line 346, in loads
return _default_decoder.decode(s)
File "/usr/lib/python3.10/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python3.10/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
```
upg-2752614
opw-4711261A test setup issue in the Kenya OSCU stock integration was corrected so sales documents can be created with the right permissions during automated checks. This helps prevent false test failures and supports more reliable validation of the module.
Original PR description
`_test_send_invoice_and_credit_note` and `_test_send_invoiced_stock_moves` try to create sale orders, but don't check that the group is set on the user. https://runbot.odoo.com/odoo/error/163637
The update fixes internal test setup so Mexican e-invoicing sales tests use the right permissions when creating sales orders. This helps prevent false test failures and improves confidence in future changes without affecting customer-facing features.
Original PR description
These tests create sale orders, but `self.env.user` does not necessarily have the right to create one by default. https://runbot.odoo.com/odoo/error/163635
Another check on the object received by the IoT Box containing certificate keys was always returning False, resulting in the certificate never being applied to the box. The object returned by odoo.com is a dictionary containing either: - 'error': 'an error message', - 'result': False (always False), or: - 'private_key_pem', - 'x509_pem', - 'subject_cn'. So checking `response.get("result")` would always return `False`, even if the server returned a certificate. Forward-Port-Of: odoo
Original PR description
Another check on the object received by the IoT Box containing certificate keys was always returning False,
resulting in the certificate never being applied to the box.
The object returned by odoo.com is a dictionary containing either:
- 'error': 'an error message',
- 'result': False (always False),
or:
- 'private_key_pem',
- 'x509_pem',
- 'subject_cn'.
So checking `response.get("result")` would always return `False`, even if the server returned a certificate.
Forward-Port-Of: odoo/odoo#206499Accounts of the following account types should generally speaking not be reconcilable: - `asset_cash` - `liability_credit_card` - `off_balance` That is why the "Allow Reconciliation" (`reconcile`) field is already invisible on the 'account.account' form and list views. After this commit - All such accounts in the standard chart of accounts are not reconcilable (there were non for `off_balance`) - The compute function on 'account.account' sets those accounts to not be reconcila
Original PR description
Accounts of the following account types should generally speaking not be reconcilable: - `asset_cash` - `liability_credit_card` - `off_balance` That is why the "Allow Reconciliation" (`reconcile`) field is already invisible on the 'account.account' form and list views. After this commit - All such accounts in the standard chart of accounts are not reconcilable (there were non for `off_balance`) - The compute function on 'account.account' sets those accounts to not be reconcilable (already done for `asset_cash`) when changing the account type. task: None Forward-Port-Of: odoo/odoo#206011
Description of the issue/feature this PR addresses: Current behavior before PR: Project users can't subscribe partners in projectw which visibility is set to 'Invited internal users': - Set a project to that visibility type. - Create a task. - Assign a user outside the project who just has 'Project user' permissions to that task. - With that user: in the task, try to subscribe a partner to the chatter. - With that user: in the chatter, try to mention a partner who's not subscribed
Original PR description
Description of the issue/feature this PR addresses: Current behavior before PR: Project users can't subscribe partners in projectw which visibility is set to 'Invited internal users': - Set a project to that visibility type. - Create a task. - Assign a user outside the project who just has 'Project user' permissions to that task. - With that user: in the task, try to subscribe a partner to the chatter. - With that user: in the chatter, try to mention a partner who's not subscribed to the task's thread. The user couldn't subscribe any user due to permission issues on project.project. Desired behavior after PR is merged: User's are able to operate normally where access is granted. OPW-4725100 MT-9830 cc @moduon @rafaelbn @EmilioPascual --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205908
After feff1a8 the distribution model uses it's fields to retrieve a matching analytic distribution. There's an incorrect behavior if a custom field is added to the model, for ex. with Studio or manually. Steps to reproduce: - add a custom field to the analytic distribution model with Studio - create an analytic distribution model and fill the custom field with a value ->> the model is not applied anymore when it should be. This is because of `_check_score` raising `NonMatchingDistrib
Original PR description
After feff1a8 the distribution model uses it's fields to retrieve a matching analytic distribution. There's an incorrect behavior if a custom field is added to the model, for ex. with Studio or manually. Steps to reproduce: - add a custom field to the analytic distribution model with Studio - create an analytic distribution model and fill the custom field with a value ->> the model is not applied anymore when it should be. This is because of `_check_score` raising `NonMatchingDistribution` if a field has a non-falsy value and it's not matching in the values dictionary. The custom fields are excluded from the check to fix this. opw-4689695 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#205670
Until version 0.9.8 of vobject we need to ignore: - DeprecationWarning in python 3.6 and after - SyntaxWarning since python 3.12 See https://github.com/py-vobject/vobject/commit/da50fdb5fa871e4c5c3420d1e2e34e7c9ce6bb30 The warning occurs only during the first precompilation of the library. It does not occur on readonly filesystem, ie runbot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206115
Original PR description
Until version 0.9.8 of vobject we need to ignore: - DeprecationWarning in python 3.6 and after - SyntaxWarning since python 3.12 See https://github.com/py-vobject/vobject/commit/da50fdb5fa871e4c5c3420d1e2e34e7c9ce6bb30 The warning occurs only during the first precompilation of the library. It does not occur on readonly filesystem, ie runbot --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#206115
This reverts commit 4c7942e6bd0459fc9014d2af4a67a68c8334bca4. Steps to reproduce ================== - Install account_accountant - Go to accounting - Close the onboarding banner => TypeError: Cannot read properties of null (reading 'context') at _preprocessAction Cause of the issue ================== With commit 4c7942e6bd04, the response when calling the action changed ```diff - {"jsonrpc": "2.0", "id": 10} + {"jsonrpc": "2.0", "id": 10, result: null} ``` https:
Original PR description
This reverts commit 4c7942e6bd0459fc9014d2af4a67a68c8334bca4.
Steps to reproduce
==================
- Install account_accountant
- Go to accounting
- Close the onboarding banner
=> TypeError: Cannot read properties of null (reading 'context')
at _preprocessAction
Cause of the issue
==================
With commit 4c7942e6bd04, the response when calling the action changed
```diff
- {"jsonrpc": "2.0", "id": 10}
+ {"jsonrpc": "2.0", "id": 10, result: null}
```
https://github.com/odoo/odoo/blob/c412f11c028a8c7ff6e6c10da0e3f9dbc55e8e80/addons/web/static/src/views/view_hook.js#L86-L89
The condition `action !== undefined` is no longer met since the result is null.
Solution
========
Since this can happen anywhere we make an RPC call and there's no easy way to detect it, we revert the commit in stable.
Forward-Port-Of: odoo/odoo#206444This PR follows the new format of the pairing code introduced in the internal PR https://github.com/odoo/internal/pull/3462/ It removes the spaces around the introduced pairing code and makes all leters uppercase before sending them to odoo iot proxy Forward-Port-Of: odoo/enterprise#82905
Original PR description
This PR follows the new format of the pairing code introduced in the internal PR https://github.com/odoo/internal/pull/3462/ It removes the spaces around the introduced pairing code and makes all leters uppercase before sending them to odoo iot proxy Forward-Port-Of: odoo/enterprise#82905