Monday, August 3, 2026
2 changes · 18.0
Enhancements to existing features
Before this commit, contains() and its variants gave the client 3 seconds, and the bus helpers 2 seconds. The problem is that the first wait after openDiscuss pays for the whole mount, /mail/data and /discuss/channel/messages. Measured from openDiscuss resolving to the message being in the DOM: - 250 to 460ms on an idle machine; - 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a busy runbot looks like, 3 of the 10 over 2 seconds; - 1474 to 6912ms with the CPU throttl
Original PR description
Before this commit, contains() and its variants gave the client 3 seconds, and the bus helpers 2 seconds. The problem is that the first wait after openDiscuss pays for the whole mount, /mail/data and…
Before this commit, contains() and its variants gave the client 3 seconds, and the bus helpers 2 seconds. The problem is that the first wait after openDiscuss pays for the whole mount, /mail/data and /discuss/channel/messages. Measured from openDiscuss resolving to the message being in the DOM:
- 250 to 460ms on an idle machine;
- 867 to 5258ms over 10 runs with the CPU throttled 4x, which is what a
busy runbot looks like, 3 of the 10 over 2 seconds;
- 1474 to 6912ms with the CPU throttled 6x, 5 of 6 over 3 seconds.
"Reactions are ordered by id" fails 1 run in 60 at 4x for that reason.
Note that a longer timeout costs nothing on a green build: the timer is cleared as soon as the element is there, so it only delays the report of a test that was going to fail anyway.
This commit raises both to 10 seconds, the delay a tour step already gets in macro.js. test_js.py runs the presets with timeout=15000, so hoot fails the test itself at 15 seconds and 10 leaves room for the rest of the test.
This should also close most of the open runbot errors shaped like:
Failed to find x of "..." (Timeout of 3 seconds). Found 0 instead.
The element does show up in those, just after the wait gave up.
https://runbot.odoo.com/odoo/error/944188
web companion https://github.com/odoo/odoo/pull/279984Slovak entities are identified by three separate numbers: the company registry number (IČO), the income tax ID (DIČ) and the VAT number (IČ DPH). Odoo already stores IČO in company_registry and IČ DPH in vat, both on res.partner. DIČ is only defined on res.company, so it cannot be recorded for customers or vendors at all. This becomes a problem for the upcoming Peppol support in Slovakia. Slovak participants are identified on the network by EAS scheme 0245, which carries the DIČ. A field that
Original PR description
Slovak entities are identified by three separate numbers: the company registry number (IČO), the income tax ID (DIČ) and the VAT number (IČ DPH). Odoo already stores IČO in company_registry and IČ DPH in vat, both on res.partner. DIČ is only defined on res.company, so it cannot be recorded for customers or vendors at all. This becomes a problem for the upcoming Peppol support in Slovakia. Slovak participants are identified on the network by EAS scheme 0245, which carries the DIČ. A field that only exists on res.company therefore cannot be used for it, neither for the sender nor for the recipient. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr