The "show warning when bus connection encounters issues" test simulates a disconnected WebSocket that fails to reconnect. In this scenario, an alert is shown to warn the user that some features may be unavailable or slow.

However, the websocket worker’s initial reconnect delay is 1.5s, with an added random jitter up to 1 second which means the first reconnect attempt can take up to 2.5s.

The test waits up to 2.5s for the alert to show, which is not always enough. The reconnect attempt alone may be that long, and under high CPU load, processing the resulting event can take even longer.

This commit reduces the initial reconnect delay and the jitter during this test, ensuring that the reconnect attempt fails and the alert is shown within the expected time.

fixes runbot-226443

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#219649

### Issue:
BIS3 XML is not valid for Peppol

### Steps to reproduce:
- Install l10n_fr_facturx_chorus_pro and switch to french company
- Activate peppol
- Create a French customer
- Under Sales and Purchase tab, set SIRET to "11000201100044"
- Under Accounting tab, set the following:
	- Invoice sending = Peppol
	- Einvoice format = BIS Billing 3.0
	- peppol_eas = France SIRET
	- peppol endpoint = 11000201100044
- Use Invoice/Invoiced smart button, then select New to create an invoice for this french customer
- Add any non-zero invoice line, then confirm
- Send and print, send to peppol
- Download the XML. The /PartyIdentification/ID element will have the schemeName attribute set.

### Cause:
Previous [commit](https://github.com/odoo/odoo/commit/0f3a9dee5cf15fa978a1857c184413003147c4a6#diff-10c62c279423109c43458eab15a3177ff5592d6570451f890fead74389bc3740) added `schemeName`. But Peppol doesn't want any `schemeName`, see the [doc](https://docs.peppol.eu/poacc/billing/3.0/rules/ubl-tc434/UBL-DT-08/).

### Solution:
The correct attribute here seems to be `schemeID`. See an [example from the docs of Peppol](https://docs.peppol.eu/poacc/billing/3.0/bis/#_parties_2). Change `schemeName` to `schemeID`.

opw-4934436

Forward-Port-Of: odoo/odoo#219586
Forward-Port-Of: odoo/odoo#219012

Description
-----------
On databases that had `sale_amazon` installed in the past, were used for sales for a certain period, then had the module uninstalled, and later attempted to re-install it, a memory error will occur.

The peak memory usage stems from `sale.order.line._compute_is_service`. The reason the compute is triggered is because of the "re-creation" of the master data products `default_product` & `shipping_product`, which writes `type`, which the compute depends on. So the compute will be triggered for all `sale.order.line` records that had those products.

This commit avoids the excessive memory usage by explicitly fetching the fields that are needed for the compute, which avoids fetching large fields like the different products' HTML descriptions.

Benchmark
---------
On a database with 400k+ `sale.order.line` with an amazon related product, installing `sale_amazon` peak memory usage was:

|        | Peak Mem. |
|--------|-----------|
| Before | 3.8 GiB   |
| After  | 580 MiB   |

Reference
---------
opw-4915892

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#219599

Before this commit, discuss RPCs like update_content were prone to race-condition that can lead to UI showing outdated content of a message that was just edited.

This happens because some store data are exclusively feed from return data of RPC whereas some store data are feed from bus notifications. Ordering of data are essentially sound among RPC returns and bus notifications, but not between the 2 groups. Therefore RPC return or bus notifications can come before or after the other one, and the ordering may be wrong and result in wrong store data.

In practice bus notifications usually before return of RPCs. Most of discuss code is robust against this ordering, even though there's likely many potential of race conditions that may happen and are genuine bugs. When bus notifications come after returned RPCs, however, problems are more apparent. This may happen when the bus notification queue is slow, but also in tests this is likely to happen because RPCs are simulated with single micro-tick whereas handling of bus notification is usually more than 1 micro-tick.

The test "Can edit message comment in chatter" is showing this problem: it's a relatively long test that interacts a lot with message edition, which has the message content being obtained from both bus notifications and RPC returns. When the CPU load is high, test takes much more time to run, e.g. 400ms becomes 2500ms. This CPU load affects barely RPC returns but bus notifications are heavily throttled and therefore causes bus notifications to come much later than expected. Test edits message twice with different content and then once without any change. The high CPU load can make test fail after 3rd edit step because the content of message is the 1st edited content instead of the last. The last edition is coming later in the bus notification, but due to timing constraints of 3 seconds assertion can lead to timeout of test because the message is not showing the most recent edited content.

Roughly:
1. message is "original message"
2. message is edited to "edited message"
3. message shows "edited message (edited)"
4. message is edited to "edited again"
5. message shows "edited again (edited)"
6. message editing is started => message content in composer is "edited message" instead of "edited again", so crash after 3 seconds

Step 6 fails because message content between 5 and 6 is changed to "edited message" from the bus notification. All previous steps had the message edited relatively quickly (500ms each) by returned RPC. The bus notifications are throttled to about 3 seconds, thus the "edited message" bus notification arrived very late when starting edition in step 5. The composer content is wrong and the contains wait for at least 3 seconds, but due to heavy throttle of bus notifications from CPU load, the test fails.

This commit fixes the issue by introducing a `busRpc()` function on bus_service and have message edition flow use this busRpc() rather than `rpc()`. This `busRpc()` function is a special flavour of `rpc()` that awaits until the RPC and related notifications have been received. `busRPC()` works by forging a UUID bus_rpc_uuid that the RPC sends back at end of RPC. The `busRPC()` function waits until this notification is received.s

This commit ensures ordering of store data received from server is good, because RPC properly awaits bus notification. Store data of RPC return makes sense after these bus notifications, but ideally it should also be sent to bus notification and business code should ignore returned data from RPC, so that ordering of store data is always good even with interleaving if discuss actions.

This also solves the race condition in the test "Can edit message comment in chatter", because each assertion of message content ensures we are in the window of data feed by related bus notifications. When a message is being edited the composer is not affected by new message content from store data of bus notifications, but the save of the message edition should necessarily have to await related bus notifications, ensuring no previous bus notifications can be feed after this store data state.

Fixes runbot 227618

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

Currently if setting a urban piper payment method on a shop and using it at checkout will not allow you to close the session.

Steps to reproduce:
-------------------
* Go in the setting and set up urban piper (no need for credentials) testing with random keys will do
* Go into the payment methods and take one of the urban piper one and assign it to a shop
* Open that shop
* Place an order and use the urban piper payment method
* Validate
* Try closing the session
> Observation: Nothing happen, we're now unable to select the menu. If doing
the same steps but in debug mode, a traceback is shown indicating a duplicate key in a t-foreach

Why the fix:
------------
The duplicate key is happening when rendering the closing popup because the function `get_closing_control_data()` was returning twice the information related to the urban piper payment method.

Even though urban piper wasn't build with the use case in mind we want to keep it possible. We avoid sending twice the urban piper methods if they were already computed in the super method.

opw-4874699

Forward-Port-Of: odoo/enterprise#90427
Forward-Port-Of: odoo/enterprise#88156

In version 17.3, the analytic mixin was introduced in budget.line model to allow to link a budget line to multiple analytic accounts belonging to different analytic plans. The issue is that we have not adapted the code in project profitability, to take those changes into account. A problematic situation could be the following:

1. We have a project where the account "X" is set to the main project plan (the first one) "Projects" BUT the account "X" actually belongs to the analytic plan "Departments" (yes, it's possible that there is a mismatch between the project plan and the analytic plan, especially after the 18.0 upgrade where "analytic_account_id" just became "account_id", no matter in which plan it was).

2. We have a budget line linked to the account "X" for the plan "Departments".

3. We want to display the budget lines in project profitability, but this line does not appear. That's because we currently only look for the budget lines belonging to the analytic plan "Projects" aka the main/first plan, that match the account "X" of the project. But as account "X" actually belongs to the analytic plan "Departments", no budget lines are found.

task-4901400
version-18.0

Forward-Port-Of: odoo/enterprise#88658