| Created Date | Type | Name | Commit Description | State | Age | Up Time | Life Time | Action |
|---|---|---|---|---|---|---|---|---|
|
open
V18 fix tour tests
|
Failed | ||||||
|
|
merged
Merged from upstream 18 260910 01
|
[FIX] account_edi_ubl_cii: prevent deferred test crash on Community test_invoice_deferred_dates sets invoice.line fields deferred_start_date/deferred_end_date on the new line's create-vals, but only the Enterprise addon account_accountant defines them. Without it installed, the test crashed on every Community build instead of being skipped. Guard it with ensure_installed("account_accountant"), the same idiom already used four times elsewhere in this file, since the fields belong to the Enterprise deferred-revenue feature and are absent here by design. Signed-off-by: David Tran <david.tran@tvtmarine.com> | Failed | |||||
|
|
merged
Merged from upstream 18 260910 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Failed | |||||
|
|
closed
Merged from upstream 18 260908 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Failed | |||||
|
|
closed
Merged from upstream 18 260906 01
|
Failed | ||||||
|
|
merged
[FIX] pos_restaurant: wait for the order sync instead of racing it
|
[FIX] pos_restaurant: wait for the order sync instead of racing it The "Check if order has a server ID" step of the test_book_and_release_table tour sampled the order's id exactly once and threw if it was not yet a number. Nothing sequenced that sample after the syncAllOrders RPC that assigns the id: the preceding waitForLoading() only waits for `body:not(:has(.loader))`, and the step's own `trigger: "body"` matches immediately. Whether the step passed was therefore decided by whether the server happened to answer first. On Viindoo's runbot it does not. Subbuild 407980 shows the step running at 02:05:36,110 and the server logging "created pos.order #563" at 02:05:36,152 - the assertion lost the race by 42 ms and the tour failed, even though the order was created successfully moments later. The margin is small and hardware-dependent, not caused by module load. Measured across 24 runs at four addons-path scales (58, 126, 293 and 1330 installed modules - the last exceeding runbot's own 1089), the server won locally by +50..+93 ms every time, and a 23x growth in installed modules moved the mean by only ~24%. Registry size, POS asset-bundle weight and third-party POS addons were each ruled out as the mechanism; what differs is how fast the machine is. Poll for the id with a deadline instead of sampling once, so the step waits for the sync it depends on rather than racing it. The thrown error is unchanged, so existing log triage still matches. The usual idiom for a non-deterministic tour step is a more specific `trigger`, letting the tour engine's own retry loop do the waiting - see 8cb86ec07ad5 "[FIX] lunch: fix non-determistic tour error". It does not transfer here: the condition is JS model state (posmodel's pos.order id), not a DOM fact, so there is no selector to wait on. Verified by constructing the failure, since the race is won on the development machine and cannot be reproduced there naturally. With a 400 ms sleep injected into pos.order.sync_from_ui, the unfixed tour fails with exactly the runbot signature ("FAILED: [7/10] ... Step Check if order has a server ID" / "Order does not have a valid server ID", delta -360 ms). With that same sleep still in place, the fixed tour passes all 10 steps (delta -320 ms - the server is still slow, the step now waits for it). With the sleep removed the fixed tour passes at +86 ms, back inside the natural baseline band, and the rest of the pos_restaurant suite is unaffected (0 failed, 0 errors; the one skip, test_13_crm_team, needs pos_sale and is pre-existing). | Killed | |||||
|
|
closed
[FIX] pos_restaurant: wait for the order sync instead of racing it
|
[FIX] pos_restaurant: wait for the order sync instead of racing it The "Check if order has a server ID" step of the test_book_and_release_table tour sampled the order's id exactly once and threw if it was not yet a number. Nothing sequenced that sample after the syncAllOrders RPC that assigns the id: the preceding waitForLoading() only waits for `body:not(:has(.loader))`, and the step's own `trigger: "body"` matches immediately. Whether the step passed was therefore decided by whether the server happened to answer first. On Viindoo's runbot it does not. Subbuild 407980 shows the step running at 02:05:36,110 and the server logging "created pos.order #563" at 02:05:36,152 - the assertion lost the race by 42 ms and the tour failed, even though the order was created successfully moments later. The margin is small and hardware-dependent, not caused by module load. Measured across 24 runs at four addons-path scales (58, 126, 293 and 1330 installed modules - the last exceeding runbot's own 1089), the server won locally by +50..+93 ms every time, and a 23x growth in installed modules moved the mean by only ~24%. Registry size, POS asset-bundle weight and third-party POS addons were each ruled out as the mechanism; what differs is how fast the machine is. Poll for the id with a deadline instead of sampling once, so the step waits for the sync it depends on rather than racing it. The thrown error is unchanged, so existing log triage still matches. The usual idiom for a non-deterministic tour step is a more specific `trigger`, letting the tour engine's own retry loop do the waiting - see 8cb86ec07ad5 "[FIX] lunch: fix non-determistic tour error". It does not transfer here: the condition is JS model state (posmodel's pos.order id), not a DOM fact, so there is no selector to wait on. Verified by constructing the failure, since the race is won on the development machine and cannot be reproduced there naturally. With a 400 ms sleep injected into pos.order.sync_from_ui, the unfixed tour fails with exactly the runbot signature ("FAILED: [7/10] ... Step Check if order has a server ID" / "Order does not have a valid server ID", delta -360 ms). With that same sleep still in place, the fixed tour passes all 10 steps (delta -320 ms - the server is still slow, the step now waits for it). With the sleep removed the fixed tour passes at +86 ms, back inside the natural baseline band, and the rest of the pos_restaurant suite is unaffected (0 failed, 0 errors; the one skip, test_13_crm_team, needs pos_sale and is pre-existing). | Failed | |||||
|
|
merged
Merged from upstream 260826 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Killed | |||||
|
|
merged
Merge from upstream 18 20260824 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Killed | |||||
|
|
merged
Merged from upstream 18 260813 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Killed | |||||
|
|
merged
[FIX] pos_sale: assert every sale picking is cancelled, not a single one
|
Killed | Not started | Not finished | ||||
|
|
merged
[FIX] pos_sale: assert every sale picking is cancelled, not a single one
|
[FIX] pos_sale: assert every sale picking is cancelled, not a single one test_settle_order_with_multistep_delivery_receipt reads sale_order.picking_ids.state, assuming the order carries exactly one delivery picking. With the foreign-trade export flow installed, the NL test partner makes the order route its delivery through the customs zone, so two chain pickings exist by the time the POS settles the order — both correctly cancelled — and the singleton access raises "Expected singleton: stock.picking(588, 587)". Assert the actual intent of the test instead ("all the picking are cancelled", per its docstring): the order has pickings and every one of them is cancelled. Still passes on a bare community stack. | Killed | Not started | Not finished | |||
|
|
merged
Merge from upstream 18 20260812 01
|
[FIX] hr_holidays: freeze the date of the accrual-levels leave test test_hr_leave_after_adding_accrual_plan_levels (introduced upstream by 55f89ed97965) books a leave covering today + 2 to today + 3 without freezing time. On a Monday-to-Friday calendar any run on a Thursday makes that window fall entirely on the weekend, so the leave counts zero days and action_validate() raises "The following employees are not supposed to work during that period". A bare community checkout of the same commit fails identically, and upstream has not fixed it yet. Freeze the test on a Monday so the leave always lands on working days, the same way 34f6bbfbaf1c already did for another test of this file. | Killed | |||||
|
|
merged
Merge from upstream 18 20260812 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Failed | |||||
|
|
merged
Merge from upstream 18 20260812 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Killed | Not finished | ||||
|
|
merged
Merge from upstream 18 20260808 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Killed | |||||
|
|
merged
[FIX] point_of_sale: adapt tour helper to integer quantity display
|
[FIX] point_of_sale: adapt tour helper to integer quantity display Commit c63e34ff56fa backported the Odoo 19 behavior of displaying whole-number quantities without a decimal part, but the tour helper still compared the raw expected quantity string ('1.0'/'1.00') against the rendered '1', breaking every orderline check step across the POS test suites. Normalize the expected quantity the same way upstream does in 456a7428f8e3 (order_widget_util.js). | Killed | |||||
|
|
merged
[IMP] point_of_sale: hide decimals for integer quantities on receipts
|
[IMP] point_of_sale: hide decimals for integer quantities on receipts Quantities were always formatted with the global 'Product Unit of Measure' decimal precision, so a quantity of 1 was displayed as 1.000 (with a 3-digit precision) on the order screen and the printed receipt, even for countable units such as Units/Piece. Backport the Odoo 19 behavior: whole-number quantities are displayed without a decimal part, while fractional quantities (e.g. 1.5 kg) keep the standard precision-based formatting. | Killed | Not finished | ||||
|
|
merged
Merged from upstream 18 260724 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Killed | |||||
|
|
closed
Merged from upstream 18 260722 01
|
[FIX] account_edi_ubl_cii: skip predictive test when account_accountant feature is absent test_partial_import_product_invoice_predictive needs the Enterprise-only invoice-history predictor (account_accountant); on Viindoo's Community stack it is absent, so the predictive path no-ops and the test asserts a product_id it cannot resolve. Guard by the SAME condition production code uses (payment_state_before_switch field absence) rather than a module name, so it stays correct regardless of which account module is installed. Upstream 9365822e (18.0-only) removed the original ensure_installed('account_accountant') guard as collateral of an unrelated settings-toggle sweep; master still carries a guard. Kept minimal to limit divergence from odoo/odoo. | Failed | |||||
|
|
closed
Merged from upstream 18 260722 01
|
Failed | ||||||
|
|
closed
Merged from upstream 18 260722 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Failed | |||||
|
|
closed
Merged from upstream 18 260716 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Failed | |||||
|
|
merged
[FIX] point_of_sale: add deterministic tiebreaker to limited product loading
|
[FIX] point_of_sale: add deterministic tiebreaker to limited product loading get_limited_products_loading ordered candidate products by is_favorite, service type, last stock move date and write_date, with no final tiebreaker. When products tie on all of those keys (e.g. non-favorite consumable products with no stock moves created in the same transaction, sharing an identical write_date = transaction_timestamp()), the LIMIT result fell back to PostgreSQL's unspecified physical scan order, making the loaded product set non-deterministic. It surfaced as an intermittent pos_loyalty test_product_loading failure on large installs. Add product_product.id as a final ascending tiebreaker so limited product loading is stable and reproducible. | Killed | |||||
|
|
merged
Merged from upstream 18 260707 01
|
Failed | ||||||
|
|
merged
Merge from upstream 18 20260615 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Failed | |||||
|
|
closed
Merge from upstream 18 20260519 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Failed | |||||
|
|
merged
Merge from upstream 18 20260512 01
|
Killed | ||||||
|
|
merged
Merge from upstream 18 20260312 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Killed | |||||
|
|
merged
Merge from upstream 18 20260312 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Failed | |||||
|
|
merged
[FWD][18.0][I18N] account*: fix i18n
|
Update vi.po | Killed | |||||
|
|
merged
Merged from upstream 18 260218 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Killed | |||||
|
|
merged
Merged from upstream 18 260216 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Killed | |||||
|
|
merged
Merged from upstream 18 260214 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Killed | |||||
|
|
merged
Merged from upstream 18 260210 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Failed | |||||
|
|
closed
Merged from upstream 18 260131 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Failed | |||||
|
|
merged
Merged from upstream 18 260125 01
|
Killed | ||||||
|
|
merged
Merged from upstream 18 260119 01
|
Merge remote-tracking branch 'upstream/18.0' into 18.0 | Killed | |||||
|
|
open
Merge from upstream 18 20250110 01
|
Merge remote-tracking branch 'odoo/18.0' into 18.0 | Killed | |||||
|
|
open
Merge from upstream 18 20250110 01
|
Failed |
