Odoo Changelog — 2024-08-15

Thursday, August 15, 2024

2 changes · saas-17.2

Bug Fixes(2)

Resolved issues and error corrections

[FIX] base: avoid setting the default 'es' url code when it's unwanted

Coresaas-17.2base

This change prevents upgrades from incorrectly reassigning the short Spanish URL code when a regional Spanish language is already using it. It helps avoid upgrade errors for databases that enabled Spanish variants such as Argentina Spanish before moving to newer versions.

Original PR description

Steps to reproduce [`17.2`]: - Start a fresh DB. - Enable one of the Spanish sub-languages except the `Spanish LATAM` (the one with default `/es` url code) e.g., `"es_AR"`. - An error is triggered…

Steps to reproduce [`17.2`]:

- Start a fresh DB.
- Enable one of the Spanish sub-languages except the `Spanish LATAM`
(the one with default `/es` url code) e.g., `"es_AR"`.
- An error is triggered when upgrading to a `17.3+` version by the code
trying to set the `'es'` url code while it was already available in
another record.

Starting from [1], we allow using the short url code `'es'` when a
Spanish sub-language is enabled (as long as `es_419` is not) [A].

We also update the records in XML to set the Spanish LATAM (`es_419`) as
the one with the default `'es'`, assuming that the `base.lang_es` record
will always hold the `'es'` url code.

Running the XML updates again in the situation of [A] will try to set
the unique `es` url code on a record while another record (other than
`base.lang_es`) is holding it (`"es_AR"` in this case).

The goal of this commit is to simply add a `noupdate` for the XML
updates so they are only loaded on initialization.

[1]: https://github.com/odoo/odoo/commit/a992d2deab9d582cc33dc31f0b1bd610f82add0d


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

#language#upgrade#spanish#url

[FIX] bus: non deterministic ir websocket test

PR #176728

Coresaas-17.2bus

This fixes an internal automated test for user presence updates so it no longer depends on timing-sensitive websocket behavior. The change helps keep test results stable and reduces false failures in development and release validation.

Original PR description

The `test_notify_on_status_change` ensures user presences are received when updated. To do so, they send a websocket message to the server. However, there is no guarantee the presence was updated after sending the message as the processing is asynchronous.

This PR fixes the issue by directly calling `_update_presence` and waitng for the answer through the websocket.

runbot-74017

#testing#websocket#stability

Steps to reproduce [`17.2`]: - Start a fresh DB. - Enable one of the Spanish sub-languages except the `Spanish LATAM` (the one with default `/es` url code) e.g., `"es_AR"`. - An error is triggered when upgrading to a `17.3+` version by the code trying to set the `'es'` url code while it was already available in another record. Starting from [1], we allow using the short url code `'es'` when a Spanish sub-language is enabled (as long as `es_419` is not) [A]. We also update the records in XML to set the Spanish LATAM (`es_419`) as the one with the default `'es'`, assuming that the `base.lang_es` record will always hold the `'es'` url code. Running the XML updates again in the situation of [A] will try to set the unique `es` url code on a record while another record (other than `base.lang_es`) is holding it (`"es_AR"` in this case). The goal of this commit is to simply add a `noupdate` for the XML updates so they are only loaded on initialization. [1]: https://github.com/odoo/odoo/commit/a992d2deab9d582cc33dc31f0b1bd610f82add0d 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

The `test_notify_on_status_change` ensures user presences are received when updated. To do so, they send a websocket message to the server. However, there is no guarantee the presence was updated after sending the message as the processing is asynchronous. This PR fixes the issue by directly calling `_update_presence` and waitng for the answer through the websocket. runbot-74017