Tuesday, March 18, 2025
7 changes · 17.0
Resolved issues and error corrections
This update renames a Romanian e-Factura settings label so it no longer conflicts with another Client ID field in Odoo. The clearer label helps users and translations distinguish the Romanian e-Factura configuration from Google OAuth settings.
Original PR description
The field `res.config.settings.l10n_ro_edi_client_id` [[1]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_config_settings.py#L7C5-L7C26) [[2]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/l10n_ro_efactura/models/res_company.py#L18) in module `l10n_ro_efactura` has the same label `Client ID` as the field `res.config.settings.auth_oauth_google_client_id` [[3]](https://github.com/odoo/odoo/blob/63e0285ade407074c8e054d6d14a71b633d55f17/addons/auth_oauth/models/res_config_settings.py#L15C5-L15C32) from module `auth_oauth`. Field labels should be unique on the same model so we can change the label and set it in the view where this setting is shown. starting `saas-17.4` the change should be applied to module `l10n_ro_edi` as the efactura was merged in it --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
This fix backports a database locale adjustment so an automated user-ordering test behaves consistently in Odoo 17.0. It helps prevent avoidable test failures across environments, improving release reliability without changing day-to-day user features.
Original PR description
Description of the issue/feature this PR addresses: This is in reference to issue #200050 which back-ports the changes for `test_13_m2o_order_loop_multi` from the 18.0 branch to the 17.0 branch.…
Description of the issue/feature this PR addresses:
This is in reference to issue #200050 which back-ports the changes for `test_13_m2o_order_loop_multi` from the 18.0 branch to the 17.0 branch. These changes have already been discussed and gone through proper channels in the 18.0 branch, however, this issue is still affecting 17.0. This causes some automated test environments to fail, as per the original discussion.
Current behavior before PR:
```py
def test_13_m2o_order_loop_multi(self):
Users = self.env['res.users']
# will sort by login desc of the creator, then by name
self.patch_order('res.partner', 'create_uid, name')
self.patch_order('res.users', 'partner_id, login desc')
kw = dict(groups_id=[Command.set([self.ref('base.group_system'),
self.ref('base.group_partner_manager')])])
u1 = Users.create(dict(name='Q', login='m', **kw)).id
u2 = Users.with_user(u1).create(dict(name='B', login='f', **kw)).id
u3 = Users.create(dict(name='C', login='c', **kw)).id
u4 = Users.with_user(u2).create(dict(name='D', login='z', **kw)).id
expected_ids = [u2, u4, u3, u1]
found_ids = Users.search([('id', 'in', expected_ids)]).ids
self.assertEqual(found_ids, expected_ids)
```
Desired behavior after PR is merged:
```py
def test_13_m2o_order_loop_multi(self):
Users = self.env['res.users']
# will sort by login desc of the creator, then by name
self.patch_order('res.partner', 'create_uid, name')
self.patch_order('res.users', 'partner_id, login desc')
kw = dict(groups_id=[Command.set([self.ref('base.group_system'),
self.ref('base.group_partner_manager')])])
# When creating with the superuser, the ordering by 'create_uid' will
# compare user logins with the superuser's login "__system__", which
# may give different results, because "_" may come before or after
# letters, depending on the database's locale. In order to avoid this
# issue, use a user with a login that doesn't include "_".
u0 = Users.create(dict(name='A system', login='a', **kw)).id
u1 = Users.with_user(u0).create(dict(name='Q', login='m', **kw)).id
u2 = Users.with_user(u1).create(dict(name='B', login='f', **kw)).id
u3 = Users.with_user(u0).create(dict(name='C', login='c', **kw)).id
u4 = Users.with_user(u2).create(dict(name='D', login='z', **kw)).id
expected_ids = [u2, u4, u3, u1]
found_ids = Users.search([('id', 'in', expected_ids)]).ids
self.assertEqual(found_ids, expected_ids)
```
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-prThis fixes an intermittent failure in mail channel subscription handling by avoiding unnecessary subscription updates when a user opens a channel they already belong to. It improves reliability of the messaging system's automated checks without changing the expected user experience.
Original PR description
Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing. Since [1], opening a thread *always* result in a bus subscription being issued (the channel is…
Before this PR, the `bus subscription is refreshed when channel is joined` test was sometimes failing. Since [1], opening a thread *always* result in a bus subscription being issued (the channel is added to the bus channels as a string). This is not required: bus subscriptions are based on user's channels (see `ir_websocket@_build_bus_channel_list`). When a new channel is added, the client subscribes again (see `toggleBusSubscription`). Channels should only be added explictly when a channel the user is not a member of is opened. This addition causes a race condition between `toggleBusSubscription` and the explicit addition of the channel, resulting in a non deterministic behavior. This PR fixes this issue: channel is only added when required, which is not the case in this test thus solving the issue. fixes runbot-106895 [1]: https://github.com/odoo/odoo/pull/174473 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
This fix ensures WhatsApp-related tests cover Mexican phone numbers that still include the extra 1 used by the WhatsApp API. It helps prevent messaging issues for Mexican contacts caused by differences between phone number standards and WhatsApp formatting.
Original PR description
Current behaviour: --- Mexican phone numbers are not managed correctly following the 2019 changes in Mexico. (Removing a 1 in phone numbers) Cause of the issue: --- The phonenumbers library removing support of mexican phone numbers starting with 1 in 8.13.38 The Whatsapp API still using the mexican phone numbers starting with 1 Fixes: --- See community commit Adding extra tests in test_whatsapp Similar to: https://github.com/odoo/enterprise/commit/a35a039e5fba569cd379b23d37ce512b5a23f7e2 opw-4473528
Miscellaneous changes
Do not apply `ustr()` to the exception obtained when sending a message Example use case: - Sending a message and adding an attached .eml file ``` File "/usr/local/lib/python3.10/site-packages/werkzeug/wrappers/response.py", line 327, in set_data value = value.encode(self.charset) UnicodeEncodeError: 'utf-8' codec can't encode characters in position 6547-6548: surrogates not allowed ``` The message must be processed, otherwise <ins>all subsequent messages will be blocked</ins>.
Original PR description
Do not apply `ustr()` to the exception obtained when sending a message Example use case: - Sending a message and adding an attached .eml file ``` File…
Do not apply `ustr()` to the exception obtained when sending a message
Example use case:
- Sending a message and adding an attached .eml file
```
File "/usr/local/lib/python3.10/site-packages/werkzeug/wrappers/response.py", line 327, in set_data
value = value.encode(self.charset)
UnicodeEncodeError: 'utf-8' codec can't encode characters in position 6547-6548: surrogates not allowed
```
The message must be processed, otherwise <ins>all subsequent messages will be blocked</ins>.
**Before**
**After**
Already solved in 18.0 indirectly since https://github.com/odoo/odoo/commit/41464b5896c00679a8f8ac4faba6bd6f1b11876d
Ping @pedrobaeza
@Tecnativa TT55423
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr
Forward-Port-Of: odoo/odoo#201871Scenario: - create a redirect 308 from route with a sitemap method (eg. /website/version) - go to /sitemap.xml (you might need to delete sitemap in attachment before) Result: you get a 500 error, with this traceback in server logs: ``` … File "/Users/odoo/src/odoo/17.0/addons/website/models/website.py", line 1333, in _enumerate_pages if rule.endpoint.func.__func__ in sitemap_endpoint_done: AttributeError: 'functools.partial' object has no attribute '__func__'. Did you mean: '__d
Original PR description
Scenario: - create a redirect 308 from route with a sitemap method (eg. /website/version) - go to /sitemap.xml (you might need to delete sitemap in attachment before) Result: you get a 500 error, with this traceback in server logs: ``` … File "/Users/odoo/src/odoo/17.0/addons/website/models/website.py", line 1333, in _enumerate_pages if rule.endpoint.func.__func__ in sitemap_endpoint_done: AttributeError: 'functools.partial' object has no attribute '__func__'. Did you mean: '__doc__'? ``` Fix: take a second level of partial (from the redirection and not the route) when handling duplicates routes. opw-4594629 opw-4614216 opw-4628703 Forward-Port-Of: odoo/odoo#200979
Versions -------- - 16.0+ Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign them as salesperson to a sales order with two lines; 3. create an draft invoice for one line; 4. assign admin as salesperson on the invoice; 5. as user, create a draft invoice for the other line (optional); 6. as user, cancel the sales order. Issue ----- If no second draft invoice was created, there's no warning displayed that a draft invoice exists. If one was creat
Original PR description
Versions -------- - 16.0+ Steps ----- 1. Have a internal user with only Sales: Own Documents access; 2. assign them as salesperson to a sales order with two lines; 3. create an draft invoice for one line; 4. assign admin as salesperson on the invoice; 5. as user, create a draft invoice for the other line (optional); 6. as user, cancel the sales order. Issue ----- If no second draft invoice was created, there's no warning displayed that a draft invoice exists. If one was created, trying to cancel will say you're not allowed to read journal entries. You are supposed to get an error when trying to modify journal entries. Cause ----- The cancel wizard doesn't check the order's invoices using sudo. Solution -------- Check the order's invoices using sudo. opw-4554639 Forward-Port-Of: odoo/odoo#201785